Bug #78125 [Asn]: Persistent php-cgi.exe access fault

Edit report at https://bugs.php.net/bug.php?id=78125&edit=1 ID: 78125 Updated by: cmb@php.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 Assigned To: cmb Block user comment: N Private report: N New Comment: 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> Previous Comments: ------------------------------------------------------------------------ [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/> ------------------------------------------------------------------------ [2019-06-09 12:38:10] aschmidt at anamera dot net The problem occurs when a minimal "phpinfo();" script is executed in IIS. However it APPEARS to only occur when both a CLI and a FastCGI application are running at the same time under 7.2.19 with OpCache enabled. I have a CLI application running as a Windows Service. After upgraded to 7.2.19 I first started IIS to get my site running again, but then the Windows Service would not start the CLI app. Baffled, I rebooted the server, which automatically starts the service. I confirmed that NOW the service WAS running. I then started IIS by hand - and whenever I run a basic phpinfo() THAT would now crash. I then stopped the service and IIS, reverted to 7.2.18 (without rebooting) and was aber to start both without problems. With that knowledge, I downloaded 7.2.19 one more time (in case of any download errors), copied it over 7.2.18 again, started the service by hand, and reproduced the IIS error. Finally, I disabled OPcache in 7.2.19 and NOW IIS was successfully running FastCGI in parallel with the CLI Service. Here the most relevant of my PHP.INI settings: precision = 14 zlib.output_compression = Off serialize_precision = -1 zend.enable_gc = On report_memleaks = On auto_globals_jit = On enable_dl = Off zend.assertions = -1 opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=3907 opcache.revalidate_freq=30 ;(per IIS .user.ini: opcache.revalidate_freq=0 ) opcache.enable_file_override=1 opcache.log_verbosity_level=2 opcache.file_cache=C:\Windows\Temp\PHP\OpCache opcache.file_update_protection=10 cgi.force_redirect=0 cgi.fix_pathinfo=1 fastcgi.impersonate=1 fastcgi.logging=1 [ExtensionList] extension=php_mysqli.dll extension=php_mbstring.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_intl.dll extension=php_curl.dll extension=php_exif.dll extension=php_xmlrpc.dll extension=php_openssl.dll extension=php_soap.dll extension=php_pdo_mysql.dll extension=php_pdo_sqlite.dll extension=php_imap.dll extension=php_tidy.dll extension=php_xsl.dll extension=php_yaml.dll extension=php_fileinfo.dll extension=php_componere.dll extension=php_win32service.dll zend_extension=php_opcache.dll [XDebug] ; Must be loaded after OpCache ! zend_extension = "C:\Program Files\PHP\v7.2\ext\php_xdebug-2.7.2-7.2-vc15-nts-x86_64.dll" xdebug.coverage_enable=0 [PHP_WINCACHE] extension=php_wincache.dll wincache.reroute_enabled=1 wincache.fcachesize=32 wincache.maxfilesize=512 session.save_handler=wincache ------------------------------------------------------------------------ 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