Bug #79040 [Ana->Csd]: Warning Opcode handlers are unusable due to ASLR (fall-back to file cache)

Edit report at https://bugs.php.net/bug.php?id=79040&edit=1 ID: 79040 Updated 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 +Status: Closed 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: Automatic comment on behalf of cmbecker69@gmx.de Revision: http://git.php.net/?p=php-src.git;a=commit;h=0cecf83b264cbbb5683ab8a843cc4a4d9c294644 Log: Fix #79040: Warning Opcode handlers are unusable due to ASLR Previous Comments: ------------------------------------------------------------------------ [2019-12-30 11:27:06] cmb@php.net 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 ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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