Bug #73885 [Opn]: Fatal Error Unable to write base address C:\windows\\ZendOPcache.MemoryBase@...

Edit report at https://bugs.php.net/bug.php?id=73885&edit=1 ID: 73885 User updated by: caaguado at xcentra dot com Reported by: caaguado at xcentra dot com Summary: Fatal Error Unable to write base address C:\windows\\ZendOPcache.MemoryBase@... Status: Open Type: Bug Package: opcache Operating System: Windows 7 to 10 PHP Version: 7.1.0 Block user comment: N Private report: N New Comment: I forgot to mention that changing either the system our user TEMP and TMP system variables to whatever values does make no difference to the fault, that is, the file is always attempted to be created at C:\WINDOWS. Previous Comments: ------------------------------------------------------------------------ [2017-01-07 00:09:44] caaguado at xcentra dot com Description: ------------ This is a follow-up bug report to #72623 (https://bugs.php.net/bug.php?id=72623) for PHP 7.1.0 on Microsoft Windows 7 through to Windows 10. Whenever php-cgi.exe is called from within Apache 2.4.25 as CGI (non Apache module version of PHP 7.1.0), the following error trace is recorded in OpCache's error log: Fri Jan 6 22:16:06 2017 (8828): Warning C:\windows\\ZendOPcache.MemoryBase@USERNAME@92497dc5fe29db25b36d9610a381dbc0 Fri Jan 6 22:16:06 2017 (8828): Fatal Error Unable to write base address Right after this, Apache immediately returns a "500 Internal Server Error" to the user's browser and records the following trace into its own error log: [Fri Jan 06 22:16:06.076457 2017] [cgi:error] [pid 5084:tid 1684] [client 127.0.0.1:58366] End of script output before headers: php-cgi.exe The error occurs just calling a simple PHP file only containing a call to PHP function "phpinfo();" Looking at the PHP 7.1.0 source code, the problem is at file/line: ext/opcache/shared_alloc_win32.c:319 when trying to fopen(mmap_base_file, "w"); The mmap_base_file variable used in fopen is returned from get_mmap_base_file(). This function calls in its turn Windows API function GetTempPath() in file/line: ext/opcache/shared_alloc_win32.c:103 It turns out that in PHP 7.1.0 the GetTempPath() Windows API call __ALWAYS__ returns "C:\WINDOWS" instead of the Windows system temporary folder (usually C:\WINDOWS\TEMP) or the user's temporary folder. Since C:\WINDOWS is a system protected directory, write access to the ZendOPcache.MemoryBase@USERNAME@... file containing OpCache's write base address fails, __UNLESS__ Apache (and so PHP 7.1.0) is called from a Windows Command Prompt window with elevated Administrator permissions (in which case the ZendOPcache.MemoryBase@USERNAME@... file is successfully created and PHP 7.1.0 works fine). The reason why the GetTempPath() Windows API call returns "C:\WINDOWS" could not be determined (is any hook or any other new API call proxying mechanism implemented in PHP 7.1.0 and not in previous PHP versions??). I've noticed that bug report #73060 (https://bugs.php.net/bug.php?id=73060) proposes a patch to get rid altogether of the ZendOPcache.MemoryBase@USERNAME@ file. I would suggest that this patch is considered for implementation if deemed feasible. Checks performed: ================= - The fault can be reproduced both with the 32-bit version of Apache Lounge and Apache Haus Apache 2.4.25, available here: http://www.apachelounge.com/download/ http://www.apachehaus.com/cgi-bin/download.plx#APACHE24VC14 - Monitoring for crashes with DebugDiag as per instructions in the "Generating backtrace, without compiler, on Win32" section, as well as with ProcDump v8.2 (command procdump.exe -e -o -t -w php-cgi.exe, tool available here: https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx), no such crashes appear. - The following event is registered in Windows' Application Event log: Level Date and Time Source Event ID Task Category Error 2017-01-06 22:16:07 Zend OPcache 5 None "The description for Event ID 5 from source Zend OPcache cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: Unable to write base address Access is denied. - The fault happens only with PHP 7.1.0 and not e.g. with PHP 7.0.14. It occurs at least in Windows 10 64-bits, Windows 8.1 64 and 32 bits and Windows 7. It also occurs when attempting it in a VirtualBox image of Windows. - The fault does NOT happen with Nginx 1.11.8 (which uses FastCGI instead of CGI. Nginx available here: http://nginx.org/en/download.html). Test script: --------------- 1. Create a temporary test folder, for example: C:\Temp\P71bug. 2. Download Apache Lounge or Apache Haus Apache 2.4.25 and unzip it in subfolder C:\Temp\P71bug\bin\a24 3. Download PHP 7.1.0 from http://windows.php.net/download#php-7.1 and unzip it in subfolder C:\Temp\P71bug\bin\p71 4. Copy the Apache configuration file at http://bugs.xtack.org/httpd.conf to folder C:\Temp\P71bug\bin\a24\conf 5. Save the following PHP 7.1.0 configuration file available at http://bugs.xtack.org/phpini.txt as file name php.ini in folder C:\Temp\P71bug\bin\p71 6. Create an index.php file in folder C:\Temp\P71bug containing the following: <?php phpinfo(); 7. Start Apache 2.4.25 up with command: .\bin\a24\bin\httpd.exe -X -f "C:\Temp\P71bug\bin\a24\conf\httpd.conf" 8. Open a browser window and point it to: http//127.0.0.1/index.php 9. The fault occurs and info is written to log files: - C:\Temp\P71bug\xtack_apache24_error.log - C:\Temp\P71bug\xtack_php71_opcache_error.log 10. If PHP 7.0.14 is unzipped to folder C:\Temp\P71bug\bin\p70 and the same php.ini file is copied to that very same folder, Apache can be started pointing httpd.conf to that folder, in order to see that PHP 7.0.14 works fine and the error doesn't happen. Expected result: ---------------- PHP 7.1.0 successfully executed without errors from within Apache 2.4.25. Actual result: -------------- 500 Internal Server Error, as per explanations given above. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73885&edit=1