Edit report at https://bugs.php.net/bug.php?id=78125&edit=1
ID: 78125
User updated by: aschmidt at anamera dot net
Reported by: aschmidt at anamera dot net
Summary: Persistent php-cgi.exe access fault
Status: Assigned
Type: Bug
Package: opcache
Operating System: Win x64
-PHP Version: 7.2.21-dev
+PHP Version: 7.3.8-dev
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Just also tested 7.3.6 up to 7.3.8-dev. BOTH problems are open:
a) the php-cgi crashes whenever OPcache is enabled!
b) phpinfo(8) crashes unconditionally, but phpinfo(55) will work.
So at this point, there appears that neither the current, nor any upcoming version supports OPcache
under Windows - and I'm worried that phpinfo(8) is failing?
Previous Comments:
------------------------------------------------------------------------
[2019-06-15 08:12:15] cmb@php.net
Thanks for the further investigation!
> OPcache IGNORES the PHP.ini "sys_temp_dir" value!
Indeed. On Windows it uses GetTempPath() instead.
On Windows, Opcache has a single Opcache instance (shared memory)
per User and PHP version. To manage this instance, it uses the
MemoryBase file. In the given case, starting FCGI for the first
time will create the Opcache instance, and the MemoryBase file
like you have described. When the CLI service is started, the
Opcache instance is found, but attaching is not possible, because
the MemoryBase file is not found, so the process terminates.
Shutting down FCGI will cause the Opcache instance to be destroyed.
Afterwards the CLI service can be started, and it creates a new
Opcache instance and MemoryBase file. If FCGI is started
afterwards, the Opcache instance is found, and the old MemoryBase
file as well, so attaching is successful if the contents of both
MemoryBase files are identical.
> There are TWO ways to work around this issue:
If I'm not mistaken, there is at least a third work-around, namely
to copy FCGI's MemoryBase file to where the CLI process expects
it, before starting the CLI process.
It might be worthwhile to pursue fixing this (i.e. use the same
MemoryBase file), but perhaps a better alternative might be to
facilitate to actually have multiple Opcache instances per user
and PHP version when needed. There is a draft[1], but it is not
yet sufficiently tested.
To avoid confusion: most of the explanations above refer to
Opcache on Windows only, and they are rather simplified.
[1] <https://github.com/cmb69/php-src/tree/opcache.cache_id>
------------------------------------------------------------------------
[2019-06-15 00:00:19] aschmidt at anamera dot net
I have spent more time narrowing down the problem with concurrent OPcache in php-cli vs. IIS
FastCGI. Hopefully this will make sense to you.
First:
1. the original problem with the php-cgi.exe access fault does seem resolved.
2. the phpinfo() problem did NOT happen with 7.2.18.
3. but, the concurrency problem with php-cli vs. FastCGI ALSO happens with 7.2.18, so it is does NOT
be have been caused by 7.2.19 (sorry...)
Here is what I found out regarding the OPcache running php-cli and FastCGI - and it seems to center
around the ZendOPcache.MemoryBase@someuserid@somehash file.
a. OPcache IGNORES the PHP.ini "sys_temp_dir" value!
b. OPcache will rely on the TEMP or TMP environment variable - which CAN be user specific!
c. If IIS starts first, with the AppPool using set to identify "UserX", then IIS will
create/update a file in C:\Windows\Temp\ZendOPcache.MemoryBase@UserX@somehash.
d. Any attempt to manually start a php-cli service also configured run der user "UserX"
will not run.
e. If you now SHUT DOWN IIS, then you can start the service. OPcache will now use the User's
environment to create C:\Users\UserX\AppData\Local\Temp\ZendOPcache.MemoryBase@UserX@somehash.
f. NOW you can restart IIS and both FastCGI and php-cli will run concurrently.
There are TWO ways to work around this issue:
1. either: opcache.enable_cli=0
2. or: Set the service to start automatically at boot (ONLY, if NOT set it to automatically start
"delayed")
Im summary:
I suspect is an issue with how OPcache manages that MemoryBase file, or in which User vs. System
Temp folder it creates that file, specially if multiple processes run under the same Windows UserID
(but one running under IIS impersonation).
------------------------------------------------------------------------
[2019-06-14 21:41:00] aschmidt at anamera dot net
PS:
The phpinfo() error results in php-cgi ending with Windows error
ERROR_INVALID_DATA (0x8007000D)
------------------------------------------------------------------------
[2019-06-14 21:21:53] aschmidt at anamera dot net
Problem 1 (persistent):
<?php phpinfo( $_GET[ 'i' ] ?? INFO_ALL ); ?>
Will work in IIS for all INFO_* values EXCEPT for INFO_MODULES.
phpinfo( 8 ) will fail in PHP.
However, opcache.php will work fine - and my own scripts seem to work.
Also, executing same phpinfo() in CLI runs without apparent problems.
Problem 2 (one-time):
Initially, after installing 7.2.21-dev, I had restarted the PHP-CLI background application is
running first (as a Windows Service) and THEN IIS PHP. This result in FASTCGI crashing with these
event log entries occur:
Zend OPcache, Event ID 2:
Unable to open base address file
The system cannot find the file specified.
Problem 3 (persistent):
If I REBOOT Windows Server, then IIS will start and run (with the exception of phpinfo() ), BUT, I
am now unable to start the PHP-CLI service.
If I STOP IIS, THEN I can start the PHP-CLI service.
This problem can be circumvented with
opcache.enable_cli=0.
In summary:
There STILL appears to be a concurrency problem with OPcache FastCGI and CLI active at the same
time.
And I there is a problem with OPcache and phpinfo(8) in IIS.
------------------------------------------------------------------------
[2019-06-14 18:07:49] cmb@php.net
Can you please try the latest snapshot[1]?
[1] <https://windows.php.net/downloads/snaps/php-7.2/r28808ca/>
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=78125
--
Edit this bug report at https://bugs.php.net/bug.php?id=78125&edit=1