You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sporadic opcache crash with apache and php-cgi.exe #11549
We recently updated our Project from PHP 7.1.6 to 8.2. Since the switch we are sporadically experiencing opcache crashes.
With PHP 7.1.6 we did not experience any opcache issues. The server hardware and opcache configuration stayed the same.
changed the title [-]Sporadically opcache crash with apache and php-cgi.exe[/-][+]Sporadic opcache crash with apache and php-cgi.exe[/+]on Jun 28, 2023
The crash happens in zend_jit_deactivate, so I'm assuming you're using the opcache JIT? If yes, does the problem go away when you disable JIT? And also, is it possible to use the latest 8.2.x release? I see you're on 8.2.3, so maybe the underling problem has been fixed in the meantime.
It's difficult to say where the problem could be. The crash dumps aren't very informative because the crash likely comes from a bug that was triggered way earlier in execution. It looks like a corruption bug somewhere.
How often does it crash? And does it always crash at the end of a request?
It would also be helpful if we had a way to reproduce the issue on our systems.
With opcache.file_cache_only=1 the it crashes once a day (Some random dll, not opcache). Today it was icuuc71.dll.
With opcache.file_cache_only=0, the opcache.dll continuously crashes for a few minutes (5-10), and then heals itself.
I dont know if it crashes at the end of the request. With opcache.file_cache_only=0, the application gets unresponsive for few minutes where the error occurs and works normally again after that timeframe.
Im afraid i dont know how to reproduce this issue since we cannot reproduce either on our machines.
It randomly occurs on our production server which is under heavy load (about 3000 users).
What also conserns me is that PHP is this message here.
Without a reproducer it will be very hard to find the root cause and fix it. The problem with crash dumps is that they're taken long after it went wrong.
Thanks for your reply,
sadly we also cannot reproduce on our local machines. Only our production server is affected.
This issues seems related i think: #12010
There will be an opcache fix related to restart crashes in 8.1.26, which will be released on Nov 26th. Would be interesting to know if that fixes this issue.
GH-8143 is fixed since PHP 8.1.26 and I assume that other crashes are unrelated and point to a different issue. However, without more information and a complete reproducer we cannot identify the root cause. Please open a new GH issue with a reproducer if you still encouter these problems.
Activity
[-]Sporadically opcache crash with apache and php-cgi.exe[/-][+]Sporadic opcache crash with apache and php-cgi.exe[/+]sagentac commentedon Jun 29, 2023
When the service crashes we also get these error message in the php error logs:
ndossche commentedon Jul 1, 2023
The crash happens in
zend_jit_deactivate, so I'm assuming you're using the opcache JIT? If yes, does the problem go away when you disable JIT? And also, is it possible to use the latest 8.2.x release? I see you're on 8.2.3, so maybe the underling problem has been fixed in the meantime.sagentac commentedon Jul 3, 2023
Thanks for your reply!
Yes we were using the jit default (tracing).
When disabling jit (off) we also experienced sproradic crashes (I dont have any dump file here).
Regarding newer versions:
I also tried PHP 8.2.7 with Apache VS17 and had the same problem.
Maybe the issue is not related to the opcache specifically, but occurs more often with opcache.
We just experienced another crash:
This time it was WS2_32.dll.
Could there be a problem with fcgid?
The settings there are
Also The apache error log says
ndossche commentedon Jul 3, 2023
It's difficult to say where the problem could be. The crash dumps aren't very informative because the crash likely comes from a bug that was triggered way earlier in execution. It looks like a corruption bug somewhere.
How often does it crash? And does it always crash at the end of a request?
It would also be helpful if we had a way to reproduce the issue on our systems.
philipphaeusle commentedon Jul 4, 2023
With
opcache.file_cache_only=1the it crashes once a day (Some random dll, not opcache). Today it was icuuc71.dll.With
opcache.file_cache_only=0, the opcache.dll continuously crashes for a few minutes (5-10), and then heals itself.I dont know if it crashes at the end of the request. With
opcache.file_cache_only=0, the application gets unresponsive for few minutes where the error occurs and works normally again after that timeframe.Im afraid i dont know how to reproduce this issue since we cannot reproduce either on our machines.
It randomly occurs on our production server which is under heavy load (about 3000 users).
What also conserns me is that PHP is this message here.
sagentac commentedon Sep 27, 2023
We just updated to 8.2.10, but unfortunately it did not solve the crashes.
ndossche commentedon Sep 27, 2023
Without a reproducer it will be very hard to find the root cause and fix it. The problem with crash dumps is that they're taken long after it went wrong.
sagentac commentedon Sep 27, 2023
Thanks for your reply,
sadly we also cannot reproduce on our local machines. Only our production server is affected.
This issues seems related i think: #12010
mvachette commentedon Nov 13, 2023
We experiment a similar problem on some production server with PHP8.1. (Windows 2019 / IIS 10)
Please find below the error messages collected, and opcache config
Error happens only on production server, under load.
We activate file cache fallback to reduce the error frequency (but error is still present sometime, and we loose performances)
IIS 10.0 Detailed Error - 500.0 - Internal Server Error
Detailed Error Information:
Module: FastCgiModule
Notification: ExecuteRequestHandler
Handler: PHP81
Error Code: 0xc0000005
Windows log
Faulting application name: php-cgi.exe, version: 8.1.22.0, time stamp: 0x64c93ded
Faulting module name: php_opcache.dll, version: 8.1.22.0, time stamp: 0x64c94350
Exception code: 0xc0000005
Fault offset: 0x0000000000013e75
Faulting process id: 0x9cc
Faulting application start time: 0x01d9d3f4eac42752
Faulting application path: c:\php81\php-cgi.exe
opcache config
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=120
opcache.save_comments=1
ndossche commentedon Nov 13, 2023
There will be an opcache fix related to restart crashes in 8.1.26, which will be released on Nov 26th. Would be interesting to know if that fixes this issue.
mvachette commentedon Dec 21, 2023
The version 8.1.26 solve the opcache.dll crashes, but on some servers, we continue to face soma random crashes of php_cgi.dll.
Here ares some error traces we have :
kamil-tekiela commentedon Nov 7, 2026
GH-8143 is fixed since PHP 8.1.26 and I assume that other crashes are unrelated and point to a different issue. However, without more information and a complete reproducer we cannot identify the root cause. Please open a new GH issue with a reproducer if you still encouter these problems.