Edit report at https://bugs.php.net/bug.php?id=73885&edit=1
ID: 73885
Comment 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: Assigned
Type: Bug
Package: opcache
Operating System: Windows 7 to 10
PHP Version: 7.1.0
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Sorry, but don't you think this is a bit too little to say about the problem? CGI or not, the
fact is that PHP 7.1 seems to not deal well with this environment propagation in Apache,
doesn't it?
Can you retrieve any recommended Apache configuration settings from the old PHP 5.5 bug report that
you mentioned, both for CGI and/or FastCGI, so I can try troubleshooting a bit more for you?
Thank you!
Previous Comments:
------------------------------------------------------------------------
[2017-01-13 01:16:36] ab@php.net
Thanks for the further feedback, @caaguado. It is not, that a similar issue were not reported
earlier, I remember some already in the times of PHP 5.5. However it was always possible to solve
this with the corresponding general setup. Furthermore, I recall it was tricky to reproduce it (and
indeed newer was) on any environments i were able to debug on. So it is not 7.1, for one.
Regarding the functionality currently used, https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992(v=vs.85).aspx
. Please check the remarks section. Obviously Apache misses the environment, so then the last
possibility is used to set tmp dir to c:\windows. If you were running it as FCGI, I would have
linked you to the FcgidInitialEnv directive, to set the corresponding env var. Unfortunately,
it's quite far from the days I used CGI pure last time :), so please lookup the corresponding
Apache configuration yourself. AFAIR, Apache doesn't always automatically propagate the
environment. I also guess, that mod_cgi is rarely touched nowadays, as the usage of CGI itself is
rare.
Frankly, in first place it makes not much sense to use shared memory for pure CGI. As soon as your
server runs idle, you it'll lose all the shared memory cache. The first request after idle will
have to populate the cache again and again. For CGI, more suitable were IMO using file cache only,
which would be in any case persistent across requests, though some slower. Or even, why not FCGI? In
7.1 it can be even decoupled from the actual server through TCP, as PHP_FCGI_CHILDREN is supported.
Regarding the other ticket you linked - I gave feedback there already. The base address file is
required only once at the process start. There is a lot of possibilities to run PHP, IMHO it would
be inconvenient to fix issues by putting workarounds, if they are solvable by the proper DevOp
operation otherwise. Of course there are workarounds, nothing is without it, but IMHO it should be
more generic and not try to fix configuration issues, etc. I'd see this case as apparently a
configuration issue of this kind, so not about touching the actual handling code. As mentioned, some
similar API or case can be for sure met elsewhere in the core or also in the dependency libraries,
which would still trace itself back to the configuration question.
Btw binaries from different PHP versions are ABI incompatible, that won't work per se.
Thanks.
------------------------------------------------------------------------
[2017-01-12 22:13:10] caaguado at xcentra dot com
Thanks Anatol, I see your point about the inherited environment and, actually, it's probably a
good lead. What we know:
- As per #73060, the problem appeared in early PHP 7.1 alphas.
- Problem reproduceable in Apache 2.4.20 through to 2.4.25 in 2 different builds (Apache Lounge and
Apache Haus).
- Nginx unaffected all this time.
- GetTempPath() used in a number of places along the codebase, yet only OpCache seemingly affected.
- The later fact makes me think that if this is an environment "propagation" issue, the
issue isn't related by the environment passed by Apache down to PHP, but from PHP to OpCache
specifically (does this make sense altogether?).
- This seems reinforced by the fact that if the Windows TEMP/TMP variables are changed, the fault
remains the same. So, whatever environment Apache passes, it is not well ultimately propagated to
OpCache...
Anyway, the person who wrote #73060 has a relevant point here: If using a file is cumbersome
anyway, why not changing the implementation to avoid it (saving some few I/O in the process),
handling everything in RAM (please kindly consider his/her patch).
Or, alternatively, why not implementing this with a new php.ini setting?
Finally, I tried to replace php_opcache.dll between 7.0 and 7.1 but since there's new
functionality has been added in 7.1 and so the API has most likely changed, PHP complained that DLL
entry points could not be found. So, I haven't been able to find out/discard whether the fault
has been eventually introduced as "collateral damage" by any of OpCode's
implementation changes in 7.1 (could you please maybe inestigate this a bit?).
How could we proceed? Is there anything I can do or test to help? Please kindly let me know ð
Thank you!
------------------------------------------------------------------------
[2017-01-12 17:06:41] ab@php.net
Thanks for the detailed report. Same as in bug #72623, nothing is changed. The CGI/FCGI process is
invoked by Apache and inherits its environment. GetTempPath() might be affected by that, too, or
even by both the system and Apache. Not only Opcache, but anything using GetTempPath will be
affected, fe sys_get_temp_dir() and others. The diff in 7.0 and 7.1 is likely about different
environment, too, because otherwise it's same CRT and same call. Not sure there could be a way
to affect these environments in Apache so it becomes effective, though the config options do exist.
Thanks.
------------------------------------------------------------------------
[2017-01-11 04:53:18] krakjoe@php.net
Assigning to you Anatol, can you take a quick look at this and reassign dmitry if necessary ?
------------------------------------------------------------------------
[2017-01-07 21:13:45] caaguado at xcentra dot com
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=73885
--
Edit this bug report at https://bugs.php.net/bug.php?id=73885&edit=1