Edit report at https://bugs.php.net/bug.php?id=79040&edit=1
ID: 79040
Patch added by: cmb@php.net
Reported by: ASchmidt at Anamera dot net
Summary: Warning Opcode handlers are unusable due to ASLR
(fall-back to file cache)
Status: Analyzed
Type: Bug
Package: opcache
Operating System: Win x64 IIS
PHP Version: 7.3.13
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
The following pull request has been associated:
Patch Name: Fix #79040: Warning Opcode handlers are unusable due to ASLR
On GitHub: https://github.com/php/php-src/pull/5038
Patch: https://github.com/php/php-src/pull/5038.patch
Previous Comments:
------------------------------------------------------------------------
[2019-12-30 11:25:53] cmb@php.net
Thanks everyone! The problem is now pretty clear.
------------------------------------------------------------------------
[2019-12-30 03:54:49] ASchmidt at Anamera dot net
Based on your analysis, I rebooted the server after setting opcache.enable_cli = 0.
Naturally, now the background processing of the Windows service php.cgi instance is not being cached
at all; however, the two IIS sites handling real-time processing no longer log errors, and the IIS
phpinfo lists OPcache being active.
I assume that supports your theory that OPcache requires additional consideration to correctly
support Windows systems having CLI and IIS scripts.
------------------------------------------------------------------------
[2019-12-29 23:28:38] nikic@php.net
So, I believe the new check correctly detects a problem here -- in this case it's not even
related to ASLR: php-cli and php-cgi are different binaries with different memory layout, so files
cached based on one will certainly not be compatible with the other. Most likely you never actually
saw issues related to this, because you did not access any files cached via php-cli with php-cgi or
vice versa.
However, I think that the actual bug here is the fact that we try to share a cache between php-cli
and php-cgi (or two separate SAPIs more generally) in the first place, which can't really work.
While on other systems this is prevented by the fork model, on Windows we should be hashing the SAPI
into the system ID (or whatever the Windows specific thing is) to make sure these receive separate
caches (we should take care to allow sharing the file cache though).
------------------------------------------------------------------------
[2019-12-29 15:50:18] ASchmidt at Anamera dot net
>> the result of a fix for 7.4.0 that was backported to 7.3.13 <<
Correct, that's what I saw in the change log - which is why I'm reporting that (at least
in my case), that "fix" broke something. OPcache will work for a command line php.exe
instance, but will fail for any and all php-cgi.exe instances, the moment the first IIS web page is
requested.
------------------------------------------------------------------------
[2019-12-29 15:46:06] ASchmidt at Anamera dot net
Yes - I can produce the fall-back consistently.
Just in case my environment/configuration is relevant to the behavior, "sys_temp_dir" is
not set in php.ini, so PHP will use the temp directory passed down from the environment, which
effects where ZendOPcache.MemoryBase is located for a particular instance. However
opcache.file_cache is set, so all the file caches are centralized.
My sequence of events is always:
- Reboot server
- a Windows service starts, launching a permanent CLI "php.exe" instance.
- I run a manual CLI "php.exe" instance, using the same Windows User, to obtain phpinfo
for the command line environment.
No log entries up to that point, phpinfo confirms OPcache working for PHP CLI.
- Open a web page on IIS Site #1 (the browser client will cause multiple secondary resources to be
served from other PHP scripts)
- There will be a ASLR log entry for each php-cgi instance.
phpinfo for that web site indicates SHM Cache is DISabled.
Wait until php-cgi instances have shut down (now only the CLI php.exe from the service is still
running)
- Open equivalent web page on IIS Site #2
- There will be a ASLR log entry for each of the newly launched php-cgi instance.
phpinfo for that web site indicates SHM Cache is DISabled.
Now here details showing one test sequence, incl. effected OPcache files and content (incl. their
location and access timestamps) you inquired about:
09:18
- server reboot.
- CLI for Windows Service starts: php.exe, process #340
- ZendOPcache is accessed in that users "temp" folder:
C:\Users\IUSR_Workgroup\AppData\Local\Temp\ZendOPcache.MemoryBase@IUSR_Workgroup@33bdc471edd0e4b556ffbde3f16192f4
Content =
0000100000000000
00007FF9359D8AB0
09:31
- run CLI from console to obtain phpinfo, impersonating same user ID
- ZendOPcache is accessed in that users "temp" folder:
C:\Users\IUSR_Workgroup\AppData\Local\Temp\ZendOPcache.MemoryBase@IUSR_Workgroup@33bdc471edd0e4b556ffbde3f16192f4
Content identical =
0000100000000000
00007FF9359D8AB0
PHPinfo confims working OPcache
Zend OPcache
Opcode Caching => Up and Running
Optimization => Enabled
SHM Cache => Enabled
File Cache => Enabled
Startup => OK
Shared memory model => win32
Cache hits => 1
Cache misses => 0
Used memory => 16965720
Free memory => 251469736
Wasted memory => 0
Interned Strings Used memory => 385920
Interned Strings Free memory => 12196544
Cached scripts => 1
Cached keys => 1
Max keys => 3907
OOM restarts => 0
Hash keys restarts => 0
Manual restarts => 0
Note: NO log entries thus far!
09:42
- request web page on IIS Site 1
- in this case, 9 php-cgi instances are launched. Each one produces the ASLR log entry:
Sun Dec 29 09:41:55 2019 (2880): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:02 2019 (852): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:11 2019 (248): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:11 2019 (2580): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:11 2019 (1488): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:11 2019 (2744): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:12 2019 (2492): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:12 2019 (1168): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:42:12 2019 (2592): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
- All 9 instances are using the file cache:
C:\Windows\Temp\PHP\OpCache\60b1385bb59ac949ca08e42b215b571d\33bdc471edd0e4b556ffbde3f16192f4\...
- A different ZendOPcache.MemoryBase is accessed at the Temp folder associated with this IIS
application pool:
C:\Windows\Temp\ZendOPcache.MemoryBase@IUSR_Workgroup@33bdc471edd0e4b556ffbde3f16192f4
Content DIFFERENT than the CLI one =
0000100000000000
00007FFA55858AB0
09:53
- previous php-cgi instances have vanished.
- request equivalent web page, but on IIS Site 2
- in this case, 2 php-cgi instances are launched (process #1572 + 2824). Each one produces the ASLR
log entry:
Sun Dec 29 09:53:23 2019 (2824): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
Sun Dec 29 09:53:34 2019 (1572): Warning Opcode handlers are unusable due to ASLR (fall-back to file
cache)
- The IIS specific ZendOPcache.MemoryBase is accessed at the Temp folder associated with this IIS
application pool:
C:\Windows\Temp\ZendOPcache.MemoryBase@IUSR_Workgroup@33bdc471edd0e4b556ffbde3f16192f4
Content DIFFERENT than the CLI one, but still the same as with Site #1 from 10 minutes earlier
0000100000000000
00007FFA55858AB0
- PHPinfo for web site:
Opcode Caching => Up and Running
Optimization => Enabled
SHM Cache => Disabled
File Cache => Enabled
Startup => OK
------------------------------------------------------------------------
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=79040
--
Edit this bug report at https://bugs.php.net/bug.php?id=79040&edit=1