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.

Unfortunately I don't have a short reproducer script aside from the application itself

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?

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
```
<?php
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.

As one more data point: 7.3.6 does not seem to be affected

Does this happen with and without Opcache being enabled?

After removing
```
zend_extension=php_opcache.dll
opcache.enable_cli=1
opcache.enable=1
```
from php.ini the problem seems to be gone. So it does indeed look like the problem is related to opcache.

Thanks!

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
related.

Sara, could you please have a look at this?

the only difference between 7.2.18 and 7.2.19 in ext/opcache is https://github.com/php/php-src/commit/5c4d125d4c2976236e2ecddd1d8c6e7b113ec482#diff-c71a95c83b8c6641638e6732d2264b55 - maybe it makes sense to create a windows build that excludes that commit to see if it still happens?

I can offer to test such a build with that commit excluded (win, x86, NTS)

7.3.6 seems to include that opcache commit as well https://github.com/php/php-src/commit/53c1b485741f31a17b24f4db2b39afeb9f4c8aba but is not affected afaics.

We're having the same issue with symfony on Ubuntu 18.04.2 after upgrading from 7.2.18 to 7.2.19

PHP 7.2.19-1+ubuntu18.04.1+deb.sury.org+1 (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 v7.2.19-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

It does not directly relate to Phpfastcache but can be any random class/file in the framework

Fully list of commits in 7.2.19: https://github.com/php/php-src/compare/PHP-7.2.18...PHP-7.2.19

Very short, the already referenced https://github.com/php/php-src/commit/5c4d125d4c2976236e2ecddd1d8c6e7b113ec482 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: https://github.com/php/php-src/commit/fa6a4483e63d87608a839d04c6e1b9eed9a0430f

The thing is, these changes should only affect opcache restarts, not normal operation.

@dmitry: Any ideas what could cause this?

@mbiebl, maybe you could test a recent snapshot[1]?  (There have
been some failing builds, but ra3e6b50 should be good now.)

[1] <https://windows.php.net/downloads/snaps/php-7.2>

@cmb: I tried with php-7.2-nts-windows-vc15-x86-ra3e6b50.zip, problem is still reproducible

I also tried php-7.2-nts-windows-vc15-x86-rad63bd1.zip, which seems to be the last successful build before https://github.com/php/php-src/commit/5c4d125d4c2976236e2ecddd1d8c6e7b113ec482#diff-c71a95c83b8c6641638e6732d2264b55

No problems with this version, which would confirm that this commit is indeed the culprit

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.

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.

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.

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.

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.

I was lead to this issue from here: https://github.com/php/php-src/pull/4161

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.

May be this patch can help https://gist.github.com/dstogov/b13163408e0edf337b99b4e634cba38f

But it's really hard to guess, without a way to reproduce the problem.

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?

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?

@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.

I've changed my php.ini to enable debug logging for opcache like this:
```
zend_extension=php_opcache.dll
opcache.enable_cli=1
opcache.enable=1
opcache.error_log="C:\Windows\temp\php_opcache.log"
opcache.log_verbosity_level=4
```
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.

We managed to find a way to reproduce. We use nginx + php-fpm 7.2.19 with the patch supplied from [email protected]

Step to reproduce

Create the following files:

test.php
----------
<?php

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

    echo 'done';

----------

test2.php
----------
<?php

require_once 'include.php';

echo 'done';

----------

include.php
----------
<?php

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.

@martijn at squeezely dot tech: Thanks a lot! I can confirm that this reproduces the issue for me.

Testcase added in https://github.com/php/php-src/commit/f8a68fd9350ac97d33d1773453c4e9d47a97b33f, with a bit of run-tests plumbing.

The issue should be fixed by https://github.com/php/php-src/commit/f1a81380554070d7f4b0c6dcd1202364ebf3d252. It would be great if you can confirm that this also fixes your original issue.

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.

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.

Seems the snapshot builder hung; now the rf1a8138 builds are in
progress.

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.

Reopening as original issue not fixed.

I've setup a build env in the mean time, so I'm happy to test any patches you throw at my direction.

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.

@mbiebl, did you try the patch suggested by dmitry[1]?

[1] <https://gist.github.com/dstogov/b13163408e0edf337b99b4e634cba38f>

I committed two more related patches

https://github.com/php/php-src/commit/91a6cdbff5ebd1ca4db1d6e8c42d3265ce80ace4
https://github.com/php/php-src/commit/96a12578c13b5c37195b10526fcdc669b795644d

I had missed 
[1] <https://gist.github.com/dstogov/b13163408e0edf337b99b4e634cba38f>

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

Will testt the other patches later (as time permits)

Thanks @mbiebl!  You can also try
<https://windows.php.net/downloads/snaps/php-7.2/r28808ca/>.

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!

Thanks for the confirmation! I'll ask the RMs to cherry-pick these fixes into the upcoming PHP 7.2 and 7.3 releases.