[php-src] Issue #7915: php_opcache crash - memory access violation

Issue: https://github.com/php/php-src/issues/7915 Comment Author: jjdunn Cristoph - thanks again for your help and advice, and very prompt replies. Much appreciated ! > Regarding opcache.memory_consumption=512; that sounds like a pretty large value; maybe you can > get away with far less I just installed https://github.com/amnuts/opcache-gui and you are correct: 512MB is far too much memory. Our production server has been up since 25-Dec (more than two weeks) and is using < 55MB of the cache, with a ~100% hit-rate on more than 1000 files. see attached screenshot.  > It is generally possible to read the value from an environment variable, or to set INI settings > via the registry (for certain folders). All of the CLI processes have the same entry-script, and all the CLI code is in the same directory, so a registry-entry probably would not work to create separate caches. However, the CLI processes are launched by the Windows task-scheduler, which executes .bat files, so perhaps setting the opcache.cache_id as an environment-variable separately in each .bat file is the way to go. I'm not sure of the exact syntax for that : I see I can do export <VAR>=<value>, but what syntax causes it to be automatically read as a php.ini value when the entry-script runs? As I mentioned previously, the CLI processes share quite a lot of code with the web-app, since they're both using the same framework and models, although different controllers and views. My intention was to have one large cache for efficiency. Do you think it may be possible to fix the memory-access-violation, if I can provide the debugging output? Or should I assume it will be too difficult, and begin implementing the separate-cache for each CLI process ? The fallback for all of this would be to disable opcache for CLI, but given that these processes execute 2000+ times/day, it seems woefully inefficient to do so.