Bug #73885 [Asn->Nab]: 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 Updated by: ab@php.net Reported by: caaguado at xcentra dot com Summary: Fatal Error Unable to write base address C:\windows\\ZendOPcache.MemoryBase@... -Status: Assigned +Status: Not a bug 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: Closing, as it's clearly something about the configuration on the level upper to PHP. Thanks. Previous Comments: ------------------------------------------------------------------------ [2017-02-07 00:26:12] ab@php.net Thanks for the further comment. Here's a quote from https://httpd.apache.org/docs/2.4/env.html ============================== First, there are the environment variables controlled by the underlying operating system. These are set before the server starts. They can be used in expansions in configuration files, and can optionally be passed to CGI scripts and SSI using the PassEnv directive. ============================== There is no PassEnv directive in your Apache config, this has hardly to do something with PHP. Either this or explicitly SetEnv will set the CGI vars. I haven't worked with CGI for edges, but specifically looked up this doc page for you :) Hopefully any similar tickets can be avoided if this one is found. Apache won't propagate the system environment, it is the default crossplatform behavior. An Apache distribution on Linux is pre configured and is integrated with the OS, so it is easy. Under Windows, having the documentation at hand is often necessary to achieve even simple things. Thanks. ------------------------------------------------------------------------ [2017-02-06 21:04:36] caaguado at xcentra dot com 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! ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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