Bug #72645 [Com]: php failed with 500 error 0xfffffffe, "Cannot create mutex" in opcache.log

Edit report at https://bugs.php.net/bug.php?id=72645&edit=1 ID: 72645 Comment by: pvasilevich at plesk dot com Reported by: pvasilevich at plesk dot com Summary: php failed with 500 error 0xfffffffe, "Cannot create mutex" in opcache.log Status: Verified Type: Bug Package: opcache Operating System: Windows PHP Version: 7.0.9 Block user comment: N Private report: N New Comment: >What i'm only concerned about is, that this would indeed split all the cache. Other >variants like mmap or SHM don't do this. I guess we could solve this by setting corresponding >security attributes. Checking currently impacts and possibilities. What I see in fact that both processes (running under the same user but in different pools) have written the same base address in their separate files (in my build of PHP). So mutex only protects exclusive access to the file, file contains memory address, and address is the same, so there is no cache split in fact. From other side I think currently concept of opcache cannot be used per application. I would like to have cache explicitly dedicated for my application with my memory limit I have specified and tuned for my application. In the same time, I want to have another cache for another application, that is working on the same server. I don't want to share any data between these applications. I don't want to share memory between these applications. I can try to configure this by having 2 different php.ini files for both my applications and explicitly selected mmap_base addresses in php.ini (guessing these addresses), but this is not user friendly to configure and you have risks that some DLLs with ASLR will be overlapped with selected address. There are things to improve in future versions. Regarding current situation, you can try to fix this by explicitly specifying Security Attributes structure when creating Mutex, but in this case you need to fetch SID of current user, and this should be not primary token (which probably will be app_pool_name), but need to resolve SID of user based on GetUserName(). > What is fastcgi.impersonate set to in your INI? > Would you include your INI configuration? I have tried both fastcgi.impersonate = 0 and fastcgi.impersonate = 1 the problem is the same my php.ini is default php.ini-production from php-7.0.9 with zend_extension=D:\php-7.0.9\ext\php_opcache.dll opcache.error_log=c:\windows\temp\opcache.log no other changes. Previous Comments: ------------------------------------------------------------------------ [2016-07-25 18:32:29] mattficken@php.net What is fastcgi.impersonate set to in your INI? Would you include your INI configuration? ------------------------------------------------------------------------ [2016-07-25 16:14:37] ab@php.net Further info - it looks like phptest owns the mutex, but it's not listed by procexp explicitly. Thanks. ------------------------------------------------------------------------ [2016-07-25 15:33:51] ab@php.net Thanks for the report and analysis. Seems you also come to the root cause of the bug #72332 :) By the current implementation, the first request served will create the mutex and become its owner. With your finding it's clear, that another app pool will fail to create a mutex with the same name. It is currently unclear, which other implications such a configuration might have. It seems, that using the identity config other than app pool will produce this issue. Probably just changing its name is the simplest solution. What i'm only concerned about is, that this would indeed split all the cache. Other variants like mmap or SHM don't do this. I guess we could solve this by setting corresponding security attributes. Checking currently impacts and possibilities. Thanks. ------------------------------------------------------------------------ [2016-07-22 07:55:47] pvasilevich at plesk dot com I have uploaded screenshot from Process Explorer: http://pasteboard.co/eszXEFkYe.png ------------------------------------------------------------------------ [2016-07-22 07:47:15] pvasilevich at plesk dot com Description: ------------ Affected OSes: Windows 7, Windows Server 2012, 2012R2 STEPS TO REPRODUCE: * create user phptest * create 2 IIS application pools (pool1 and pool2), configure these pools to use this common user phptest as identity (pool->Advanced Settings->Process Model->Identity = phptest) * create 2 different sites with php handler 7.0.9 64-bit, first one is working under pool1 and another one under pool2 users. * try to open sample page with phpinfo() for one site - it is working fine * try to open similar sample page with phpinfo() on another site. Got: HTTP Error 500.0 - Internal Server Error D:\php-7.0.9\php-cgi.exe - The FastCGI process exited unexpectedly Error Code 0xfffffffe After some analysis, I have found that in opcache log (if you have enabled it before in php.ini) you can find the following entry: Fri Jul 22 13:15:23 2016 (24780): Fatal Error Cannot create mutex I have checked mutex created by first process php-cgi.exe interesting thing: mutex name contains real user name (phptest) but security attributes of this mutex don't have permissions for this user, but have permissions for special internal IIS pool user (named the same way as pool named). see screenshot. second process is working under the same user phptest, but cannot access to the mutex, because second process is working in another pool. So the error appeared. The same issue is in php5.5 and php5.6 As fast workaround for php 5.5 (which was originally needed for me) I have tried to compile opcache that also checks env variable APP_POOL_ID (set by IIS) and if it is not empty, add this to both mmap base filename and to mutex name. Test script: --------------- <?php phpinfo(); ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=72645&edit=1