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

Edit report at https://bugs.php.net/bug.php?id=73060&edit=1 ID: 73060 Updated by: cmb@php.net Reported by: pvasilevich at plesk dot com Summary: php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up -Status: Wont fix +Status: Re-Opened Type: Bug Package: opcache Operating System: Windows PHP Version: 7.0.10 -Assigned To: ab +Assigned To: cmb Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2020-07-20 12:08:18] cmb@php.net The following pull request has been associated: Patch Name: Fix #73060: php failed with error after temp folder cleaned up On GitHub: https://github.com/php/php-src/pull/5875 Patch: https://github.com/php/php-src/pull/5875.patch ------------------------------------------------------------------------ [2017-01-12 17:52:26] ab@php.net Thanks for the idea. As for me, the issue with a file is not bigger and not smaller, than an issue with a memory segment. Really, it's hard to buy both arguments - whether it's a poorly written cleanup script, or it's a rare case that might never happen. With address placed in memory - well, at some point it might fail to attach to the memory segment, too :) In that case, a file is more reliable. Of course, when going into temp dir and carelessly deleting everything, many programs will be broken, any OS actually. On PHP side, it's a clean exit though, no crash. IMO, it's a configuration question, same one would telling ocassionally deleting a session file would be an "issue" of same art. Also about users, AFAIR it were discussed in another ticket - while any configuration is possible, the most convenient and secure is by using an app pool identity. As for me, really hard to buy a need on such change - either way it's up to a DevOp to configure it right, while an overall improvement is questionable. Thanks. ------------------------------------------------------------------------ [2017-01-09 06:36:29] krakjoe@php.net Anatol, assigning to you for review. ------------------------------------------------------------------------ [2016-09-10 01:45:09] pvasilevich at plesk dot com 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 this bug report at https://bugs.php.net/bug.php?id=73060&edit=1