Bug #73060 [NEW]: php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up

From: pvasilevich at plesk dot com Operating system: Windows PHP version: 7.0.10 Package: opcache Bug Type: Bug Bug description:php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up Description: ------------ Install PHP 7.0.10 Configure application pool running under user 'phptest' create site in IIS, add PHP as FastCGI handler on this site. access web site from browser. Notice that after that file ZendOPcache.MemoryBase@phptest@d49cef08b45d979de985be7086837d8d appeared in C:\Windows\Temp Everything is working fine. After that this file was removed by some cleanup script (or manually). FastCGI process php-cgi.exe is still working. After that if incoming request need to launch second FastCGI child process, it will be crashed with: HTTP Error 500.0 - Internal Server Error The FastCGI process exited unexpectedly Error Code 0xfffffffe opcache.error_log directive is enabled, so logs are collected in file. We have the following error: Fri Sep 9 17:22:19 2016 (10880): Fatal Error Unable to open base address file Easiest way is to reproduce this, if you have test script: <?php sleep(5); and request such page in 2 browsers or 2 tabs (so new FastCGI child need to be started to handle request) Storing this file in C:\Windows\Temp is risky. If this file is removed, you will get broken website. Also, similar problem may appear if you have site configured under some user, file ZendOPcache.MemoryBase@USER will be created and will have Full Access permissions for USER SID, but this file is never deleted by PHP. So if for some reasons you have removed this user from system, and then created again, PHP will try to open this file under another SID and will fail to do that. I understand that this scenario is pretty rare, but looks like idea to store base address in file is not very robust solution. I have found request https://github.com/zendtech/ZendOptimizerPlus/issues/121 to have ability to move this file into custom place, but still, this cannot solve the problem if such file is removed occasionally. I want to propose idea, how to get rid of that file assuming that we still need to share between processes information about base address need to be used for mapping shared memory in process address space. Idea is: we can create another small named shared memory object. Name of this shared memory is the same as current file name - ZendOPcache.MemoryBase@USER@PHPID this shared memory contains only single pointer (void*) inside. This is base address of memory which should be use to map main shared memory "ZendOPcache.SharedMemoryArea@USER@PHPID". this shared memory (which contains only base address) can be mapped to any address inside of php process. We are storing only one address inside. lifetime of this "base address" shared memory is equal to main shared memory, permissions to access to this memory is the same as for main memory. This memory will be automatically removed, when there are no more PHP processes holding HANDLE to that memory (together with main memory). I have tested this approach in PHP 5.6 (patch will be uploaded) and it works as expected. I guess this can decrease number of times PHP users on Windows are facing some issues with this file. -- Edit bug report at https://bugs.php.net/bug.php?id=73060&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=73060&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=73060&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=73060&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=73060&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=73060&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=73060&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=73060&r=needscript Try newer version: https://bugs.php.net/fix.php?id=73060&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=73060&r=support Expected behavior: https://bugs.php.net/fix.php?id=73060&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=73060&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=73060&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=73060&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=73060&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=73060&r=dst IIS Stability: https://bugs.php.net/fix.php?id=73060&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=73060&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=73060&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=73060&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=73060&r=mysqlcfg