php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73060 php failed with 500 error 0xfffffffe after C:\Windows\Temp directory cleaned up
Submitted: 2016-09-10 01:45 UTC Modified: 2020-07-28 12:47 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: pvasilevich at plesk dot com Assigned: cmb (profile)
Status: Closed Package: opcache
PHP Version: 7.0.10 OS: Windows
Private report: No CVE-ID: None
 [2016-09-10 01:45 UTC] 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.



Patches

use_shared_memory_instead_memory_base_address_file (last revision 2016-09-10 01:45 UTC by pvasilevich at plesk dot com)

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-09 06:36 UTC] krakjoe@php.net
-Assigned To: +Assigned To: ab
 [2017-01-09 06:36 UTC] krakjoe@php.net
Anatol, assigning to you for review.
 [2017-01-12 17:52 UTC] ab@php.net
-Status: Assigned +Status: Wont fix
 [2017-01-12 17:52 UTC] 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.
 [2020-07-20 12:08 UTC] 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
 [2020-07-28 12:47 UTC] cmb@php.net
-Status: Wont fix +Status: Re-Opened -Assigned To: ab +Assigned To: cmb
 [2020-07-29 08:18 UTC] cmb@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=9a744c66e70d34293eb3726cc9d17a3ddc052e30
Log: Fix #73060: php failed with error after temp folder cleaned up
 [2020-07-29 08:18 UTC] cmb@php.net
-Status: Re-Opened +Status: Closed
 [2020-07-29 16:32 UTC] cmb@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=2bcc419800f0974609804cc00e345c8609291fc9
Log: Fix #73060: php failed with error after temp folder cleaned up
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Oct 13 13:01:27 2024 UTC