php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #70435 Wrong return type when opcache is enabled
Submitted: 2015-09-05 19:50 UTC Modified: 2015-10-04 04:22 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: peehaa@php.net Assigned:
Status: No Feedback Package: opcache
PHP Version: 7.0.0RC2 OS: Windows 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: peehaa@php.net
New email:
PHP Version: OS:

 

 [2015-09-05 19:50 UTC] peehaa@php.net 
Description:
------------
When running on apache with opcache enabled I get a TypeError on the return value. However the actual return type it is complaining about is different than the return type I have defined.

It seems as if the CLI is not affected by this.

I tried to isolate the problem code as far as I could, but I couldn't get it any smaller than this https://github.com/CodeCollab/Demo/tree/opcache-return-type-bug

At some point it suddenly started working as it should, but after an apache restart the problem was back.

I will add the specific part of the code that results in the error below but the actual (working) test case is the linked github repo above.

The part that throws is https://github.com/CodeCollab/Demo/blob/opcache-return-type-bug/vendor/codecollab/router/src/Router.php#L21.

Windows 7, Apache 2.4.12, PHP RC2

Test script:
---------------
    public function addRoute(string $verb, string $path, array $callback): Router
    {
        $this->routeCollector->addRoute($verb, $path, $callback);

//var_dump($this); // object(CodeCollab\Router\Router)#5 (4) { ... }
        return $this;
    }

Expected result:
----------------
Instance of CodeCollab\Router\Router is returned.

Actual result:
--------------
Fatal error: Uncaught TypeError: Return value of CodeCollab\Router\Router::addRoute() must be an instance of FastRoute\RouteCollector, instance of CodeCollab\Router\Router returned in C:\Users\PeeHaa\Desktop\ph\Websites\CodeCollabLib\Demo\vendor\codecollab\router\src\Router.php on line 21 in

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-06 15:46 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2015-09-06 15:47 UTC] laruence@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.
 [2015-09-06 16:18 UTC] danack@php.net
-Status: Feedback +Status: Open
 [2015-09-06 16:18 UTC] danack@php.net 
Laruence, the bug appears to only happen when there are multiple scripts involved. It does not happen inside a single script.

Can you give some more usable advice on how to proceed, rather than insisting on it being demonstrated in a single script? 

The reporter is known to be reasonably competent, they'll be able to follow your instructions...but they aren't able to reproduce a bug under conditions where it is known not to occur.
 [2015-09-06 16:28 UTC] peehaa@php.net 
I realized the repro code is larger than optimal laurence. As stated in my OP I have tried to isolate and minimize the problem code as far as I could.

The fact that it is about opcache heisenbugs also doesn't really help.

I tried to make it as easy and convenient as possible by creating a repo for it which can just be run on a webserver without much hassle.

If you have any idea how I could submit a couple of lines with the problem code which starts with <?php and ends with ?> I am more than happy to provide it, but as of now I have no idea how I could possibly fulfill your request.
 [2015-09-25 10:48 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-09-25 10:48 UTC] ab@php.net 
@peehaa I've just pulled your reproduce repo, testing with the todays PHP-7.0, but cannot reproduce it. Either it has been fixed inbetween by something else, or i'm doing something wrong. Please check again with some recent snapshots (or ping if you need me to provide one).

Thanks.
 [2015-09-25 15:32 UTC] peehaa@php.net 
I tried with RC3 as well, same problem.

I will try to set up some debugging tools on my machine this weekend and find out whether I can provide more info.

Will let you know and thanks for looking into it so far.
 [2015-09-25 17:58 UTC] peehaa@php.net 
I forgot to ask you Anatol. What environment did you test it on?
 [2015-09-26 16:07 UTC] ab@php.net 
Pieter,

yeah, as you've said - Apache from apachelounge.com, PHP-7.0, 64-bit. The only relevant ini is opcache.enabled=1. It might good be something in your opcache options. But otherwise - yep, if you could play with the configs, maybe you'll figure out what is causing it. I'll then try to repro with RC3 as well.

Thanks.
 [2015-10-04 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 03:01:27 2024 UTC