|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78106 Path resolution fails if opcache disabled during request
Submitted: 2019-06-04 17:53 UTC Modified: 2019-06-17 13:36 UTC
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: mbiebl at messageconcept dot com Assigned: dmitry (profile)
Status: Closed Package: opcache
PHP Version: 7.2.19 OS: Windows Server 2016 / IIS 10
Private report: No CVE-ID: None
 [2019-06-04 17:53 UTC] mbiebl at messageconcept dot com
I have a php application (which I unfortunately can't share) which uses phpfastcache 7.* from (via composer)

After the update from 7.2.18 to 7.2.19, the application is broken an I get the following error in the php log:

[04-Jun-2019 17:43:55 UTC] PHP Fatal error:  Uncaught Error: Class 'Phpfastcache\Config\Config' not found in C:\src\localhost\server.php:104
Stack trace:
#0 {main}
  thrown in C:\src\localhost\server.php on line 104

The class exists at vendor/phpfastcache/phpfastcache/lib/Phpfastcache/Config/Config.php and downgrading back to 7.2.18 makes the application work again flawlessly.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-04 18:04 UTC]
-Status: Open +Status: Feedback
 [2019-06-04 18:04 UTC]
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.

 [2019-06-04 18:08 UTC] mbiebl at messageconcept dot com
-Status: Feedback +Status: Open
 [2019-06-04 18:08 UTC] mbiebl at messageconcept dot com
Unfortunately I don't have a short reproducer script aside from the application itself
 [2019-06-04 18:14 UTC]
-Status: Open +Status: Feedback
 [2019-06-04 18:14 UTC]
I don't see anything in the 7.2.19 changelog that looks relevant, and it's going to be hard to reproduce and test without being able to see it happening...

How much debugging have you done? Is the autoloader running? Can it locate the class/file? What happens if you require() the file manually?
Does the 7.2.19 setup exactly match the 7.2.18 setup? What else is changing besides the version of PHP?
 [2019-06-04 18:14 UTC]
-Package: Reproducible crash +Package: *General Issues
 [2019-06-04 18:54 UTC] mbiebl at messageconcept dot com
The setup is identical between 7.2.18 and 7.2.19. The application is unchanged, php.ini is the same.

The PHP version I'm using is the Windows x86 NTS build.
IIS uses PHP via FCGI.

The application is a CardDAV server built on top of sabre/dav.
I tried to create a minimal test case which simply does
require_once 'vendor/autoload.php';
$config = new \Phpfastcache\Config\Config();
but this works just fine and doesn't trigger the fatal error, so I'm a bit stuck at providing a minimal test case. 
What I can do offer to do, is to try test builds. Unfortunately I don't have the toolchain to build those windows binaries myself, but if you can provide such binaries, we could do a git bisect run this way.

Other then that, I'd be glad to provide you with more information or try any debugging steps. Just let me know.
 [2019-06-04 19:34 UTC] mbiebl at messageconcept dot com
-Status: Feedback +Status: Open
 [2019-06-04 19:34 UTC] mbiebl at messageconcept dot com
As one more data point: 7.3.6 does not seem to be affected
 [2019-06-04 21:21 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-06-04 21:21 UTC]
Does this happen with and without Opcache being enabled?
 [2019-06-04 21:40 UTC] mbiebl at messageconcept dot com
-Status: Feedback +Status: Assigned
 [2019-06-04 21:40 UTC] mbiebl at messageconcept dot com
After removing
from php.ini the problem seems to be gone. So it does indeed look like the problem is related to opcache.
 [2019-06-04 21:59 UTC]
-Package: *General Issues +Package: opcache -Assigned To: cmb +Assigned To: pollita
 [2019-06-04 21:59 UTC]

Bug #78103 (and maybe bug #78101) also reports an Opcache related
regression in PHP 7.2.19 (but not PHP 7.3.6), which *might* be

Sara, could you please have a look at this?
 [2019-06-05 07:08 UTC]
the only difference between 7.2.18 and 7.2.19 in ext/opcache is - maybe it makes sense to create a windows build that excludes that commit to see if it still happens?
 [2019-06-05 09:48 UTC] mbiebl at messageconcept dot com
I can offer to test such a build with that commit excluded (win, x86, NTS)
 [2019-06-05 13:38 UTC] mbiebl at messageconcept dot com
7.3.6 seems to include that opcache commit as well but is not affected afaics.
 [2019-06-05 14:52 UTC] martijn at squeezely dot tech
We're having the same issue with symfony on Ubuntu 18.04.2 after upgrading from 7.2.18 to 7.2.19

PHP (fpm-fcgi) (built: May 31 2019 11:17:15)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache, Copyright (c) 1999-2018, by Zend Technologies

It does not directly relate to Phpfastcache but can be any random class/file in the framework
 [2019-06-05 15:14 UTC]
Fully list of commits in 7.2.19:

Very short, the already referenced is the only one that looks at all relevant.

There was a later fix to this area that did not make it into 7.2:

The thing is, these changes should only affect opcache restarts, not normal operation.
 [2019-06-05 15:18 UTC]
-Assigned To: pollita +Assigned To: dmitry
 [2019-06-05 15:18 UTC]
@dmitry: Any ideas what could cause this?
 [2019-06-05 16:24 UTC]
@mbiebl, maybe you could test a recent snapshot[1]?  (There have
been some failing builds, but ra3e6b50 should be good now.)

[1] <>
 [2019-06-05 16:42 UTC] mbiebl at messageconcept dot com
@cmb: I tried with, problem is still reproducible
 [2019-06-05 16:55 UTC] mbiebl at messageconcept dot com
I also tried, which seems to be the last successful build before

No problems with this version, which would confirm that this commit is indeed the culprit
 [2019-06-06 02:28 UTC] ani2life at gmail dot com
I'm having a similar problem.

PHP-FPM 7.3.6 + Apache 2.4.38 + Ubuntu 18.04

If enable opcache and use require_once, it will Failed opening file.
But disable opcache or use require or PHP 7.3.5, it will OK.
 [2019-06-06 09:34 UTC] mbiebl at messageconcept dot com
I have to add that this fatal error is not 100% reproducible here in the sense that I don't get it on every request. If I switch logging from debug to production mode it feels like it takes longer until I hit this error. This smells like a race condition.
 [2019-06-06 09:39 UTC] mbiebl at messageconcept dot com
Once I get this failure, the php process seems to be in a broken state and I then get it on every request. Only thing that helps is then to kill the php process (via iisreset) and let it be respawned. Then it will work again for a while until I hit the problem again at which point only a iisreset help.
 [2019-06-06 10:02 UTC] mbiebl at messageconcept dot com
One more observation: The problem only seems to happen if I have at least 2 php-cgi.exe processes. If I have two or more clients access the server at the same time, the failure is triggered immediately. With a single client and only one php-cgi.exe process running, it seems like the failure is not triggered.
 [2019-06-11 12:20 UTC]
We're having a hard time reproducing this issue. Could you please provide your opcache ini configuration(s)? I'd also be interested if the people who see this on Debian/Ubuntu are using FPM.
 [2019-06-11 13:08 UTC] michel at weimerskirch dot net
I was lead to this issue from here:

Our setup on the affected machines is PHP 7.2.19 or 7.3.6 with opcache enabled.

Deactivating opcache or going back to 7.2.18 or 7.3.5 also "solve" the problem for us, just like for the user "ani2life".

As to the ini configuration, we tried a few combinations, but even with everything set to default the error sometimes appears.

Yes, we run FPM on Ubuntu.
 [2019-06-11 13:26 UTC]
May be this patch can help

But it's really hard to guess, without a way to reproduce the problem.
 [2019-06-11 13:28 UTC]
Thanks for the information!

If this issue only occurs sporadically, is there any correlation with opcache restarts? That is, does the error occur around the same time that an opcache restart even occurs?
 [2019-06-11 19:59 UTC] mbiebl at messageconcept dot com
How can I find out if there was an opcache restart? Is there a way to get a more verbose debug log from the opcache module?
 [2019-06-11 20:24 UTC]
@mbiebl at messageconcept dot com: Assuming you already have opcache.error_log configured, if you set opcache.log_verbosity_level=4 it will capture all log messages. Maybe a lower level is enough to log non-user restarts, but I'm not sure.
 [2019-06-12 15:18 UTC] mbiebl at messageconcept dot com
I've changed my php.ini to enable debug logging for opcache like this:
Unfortunately, this didn't produce any useful log messages.
I only get messages like this:
Wed Jun 12 17:11:38 2019 (4748): Message Cached script 'C:\src\server\localhost\vendor\psr\log\Psr\Log\LoggerInterface.php'
Wed Jun 12 17:11:38 2019 (4748): Message Added key 'C:\src\server\localhost\vendor\composer/../psr/log/Psr/Log\LoggerInterface.php'
Also, this is only for one php process (4748), while I have multiple processes.
 [2019-06-13 08:35 UTC] martijn at squeezely dot tech
We managed to find a way to reproduce. We use nginx + php-fpm 7.2.19 with the patch supplied from

Step to reproduce

Create the following files:


    ini_set('opcache.enable', 0);
    require_once 'include.php';

    echo 'done';



require_once 'include.php';

echo 'done';



echo 'included';

1. Request test.php
2. Request test2.php
3. Request test.php

Final test.php request will break. 
We also tried this with require instead of require_once but this did NOT break.

Hope this helps you fix this bug. If we need to retest with a certain patch in place let me know.
 [2019-06-13 08:43 UTC]
-Status: Assigned +Status: Verified
 [2019-06-13 08:43 UTC]
@martijn at squeezely dot tech: Thanks a lot! I can confirm that this reproduces the issue for me.
 [2019-06-13 10:49 UTC]
-Summary: PHP Fatal error: Uncaught Error: Class 'Phpfastcache\Config\Config' not found +Summary: Path resolution fails if opcache disabled during request
 [2019-06-13 10:49 UTC]
Testcase added in, with a bit of run-tests plumbing.
 [2019-06-13 10:54 UTC]
Automatic comment on behalf of
Log: Fixed bug #78106
 [2019-06-13 10:54 UTC]
-Status: Verified +Status: Closed
 [2019-06-13 10:57 UTC]
The issue should be fixed by It would be great if you can confirm that this also fixes your original issue.
 [2019-06-13 11:02 UTC] mbiebl at messageconcept dot com
Just curious: In my case, there is no explicit `ini_set('opcache.enable', 0);` anywhere in the code so I wonder if this really fixes my original issue. Are there other mechanisms which implicitly disable opcache during runtime?
Anyway, I'm happy to test it once a (daily) build is available with this commit.
 [2019-06-13 11:20 UTC] mbiebl at messageconcept dot com
Since I can only reproduce that issue with 7.2.19, I would need a daily build from the 7.2 branch with that fix included.
 [2019-06-13 13:33 UTC]
Seems the snapshot builder hung; now the rf1a8138 builds are in
 [2019-06-13 14:15 UTC] mbiebl at messageconcept dot com
I tried f1a81380554070d7f4b0c6dcd1202364ebf3d252 from the PHP-7.2 branch. Unfortunately the problem is not fixed here and I get the exact same error as with 7.2.19.
 [2019-06-13 14:21 UTC]
-Status: Closed +Status: Re-Opened
 [2019-06-13 14:21 UTC]
Reopening as original issue not fixed.
 [2019-06-13 14:22 UTC] mbiebl at messageconcept dot com
I've setup a build env in the mean time, so I'm happy to test any patches you throw at my direction.
 [2019-06-13 19:41 UTC] mbiebl at messageconcept dot com
Since I had setup a build env, I did run "git bisect" and can confirm that 5c4d125d4c is indeed the first faulty commit.
For testing purposes I also checked out the PHP-7.2.19 branch and reverted that particular commit and everything was working again.
 [2019-06-14 09:53 UTC]
@mbiebl, did you try the patch suggested by dmitry[1]?

[1] <>
 [2019-06-14 10:34 UTC] mbiebl at messageconcept dot com
I had missed 
[1] <>

First tests with this patch look promising. No exceptions so far.

Will testt the other patches later (as time permits)
 [2019-06-14 18:06 UTC]
Thanks @mbiebl!  You can also try
 [2019-06-17 13:25 UTC] mbiebl at messageconcept dot com
I now also tested a current PHP-7.2 branch (03db04c3aba03fd55c94c9d834a6c151e351cfc5) with the two backports from @dmitry. 
Everything is looking fine now and you can mark the issue as resolved as far as I am concerned.

Thanks a lot everyone for the excellent support!
 [2019-06-17 13:36 UTC]
-Status: Re-Opened +Status: Closed
 [2019-06-17 13:36 UTC]
Thanks for the confirmation! I'll ask the RMs to cherry-pick these fixes into the upcoming PHP 7.2 and 7.3 releases.
 [2019-06-18 05:49 UTC]
Automatic comment on behalf of
Log: Fixed bug #78106
 [2019-06-18 07:13 UTC]
Automatic comment on behalf of
Log: Fixed bug #78106
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Mar 02 16:01:32 2024 UTC