From: caaguado at xcentra dot com
Operating system: Windows 7 to 10
PHP version: 7.1.0
Package: opcache
Bug Type: Bug
Bug description:Fatal Error Unable to write base address C:\windows\\ZendOPcache.MemoryBase@...
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 bug report at https://bugs.php.net/bug.php?id=73885&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=73885&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=73885&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=73885&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=73885&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=73885&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=73885&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=73885&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=73885&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=73885&r=support
Expected behavior: https://bugs.php.net/fix.php?id=73885&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=73885&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=73885&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=73885&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=73885&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=73885&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=73885&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=73885&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=73885&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=73885&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=73885&r=mysqlcfg