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

From: Date: Mon, 09 Jan 2017 06:36:30 +0000
Subject: Bug #73060 [Opn]: php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-206428@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73060&edit=1 ID: 73060 Updated by: krakjoe@php.net Reported by: pvasilevich at plesk dot com Summary: php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up Status: Open Type: Bug Package: opcache Operating System: Windows PHP Version: 7.0.10 -Assigned To: +Assigned To: ab Block user comment: N Private report: N New Comment: Anatol, assigning to you for review. Previous Comments: ------------------------------------------------------------------------ [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

« previous php.bugs (#206428) next »