|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81679 Tracing JIT crashes on reattaching
Submitted: 2021-11-30 22:50 UTC Modified: 2021-12-15 14:35 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: alex at ndros dot com Assigned:
Status: Closed Package: JIT
PHP Version: 8.0.13 OS: Windows Server 2019
Private report: No CVE-ID: None
 [2021-11-30 22:50 UTC] alex at ndros dot com

We have discovered that as soon as we turn on jit with the following config;


We (what it seems to be randomly) get crashes. Also, CPU get's compeltely bottlenecked at 100% until we do IISRESET.

C:\Program Files\PHP\v8.0\php-cgi.exe - The FastCGI process exited unexpectedly
Module	   FastCgiModule
Handler	   php-8.0.13
Error Code	   0xc0000005


Faulting application name: php-cgi.exe, version:, time stamp: 0x619429f5
Faulting module name: php_opcache.dll, version:, time stamp: 0x61942d4a
Exception code: 0xc0000005
Fault offset: 0x000000000012a7cd
Faulting process id: 0x8b38
Faulting application start time: 0x01d7e63c092eb6ad
Faulting application path: C:\Program Files\PHP\v8.0\php-cgi.exe
Faulting module path: C:\Program Files\PHP\v8.0\ext\php_opcache.dll
Report Id: c9a1f978-17d7-4a3f-a340-3051ebe97f58
Faulting package full name: 
Faulting package-relative application ID: 


Fault bucket 1348990199055715320, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: php-cgi.exe
P3: 619429f5
P4: php_opcache.dll
P6: 61942d4a
P7: c0000005
P8: 000000000012a7cd

Attached files:

These files may be available here:

Analysis symbol: 
Rechecking for solution: 0
Report Id: c9a1f978-17d7-4a3f-a340-3051ebe97f58
Report Status: 268435456
Hashed bucket: 407a7897610279d7c2b8937054330bf8
Cab Guid: 0


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-11-30 22:50 UTC] alex at ndros dot com
This seem to happen to any PHP application.
 [2021-12-01 11:03 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-12-01 11:03 UTC]
I cannot reproduce this.

> This seem to happen to any PHP application.

Can you give a concrete example?  Ideally, a minimal application
or even better a simple script.

A stack backtrace[1] might also be helpful.

[1] <>
 [2021-12-08 12:16 UTC] ian dot fitzgerald at emapplications dot com
We also have this issue with our Wordpress website on Server 2019 after upgrading PHP7.3->8.0 and enabling opcache+JIT. From basic observation this seems to happen as soon as a second FastCGI php-cgi instance is started by IIS (instance limit set to 4).

I have generated this stack backtrace:

Faulting Thread entry point: php_cgi!mainCRTStartup 

php_opcache!zend_jit_trace_exit+7d [D:\a\php-ftw\php-ftw\php\vs16\x64\php-8.0.13\ext\opcache\jit\zend_jit_trace.c @ 7443 + 14]
php8!zend_fetch_class+a0 [D:\a\php-ftw\php-ftw\php\vs16\x64\php-8.0.13\Zend\zend_execute_API.c @ 1509 + 9]

Exception information:
xxxx.dmp the assembly instruction at php_opcache!zend_jit_trace_exit+7d in C:\Program Files\php8\ext\php_opcache.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000074 on thread 0
 [2021-12-08 13:57 UTC]
-Status: Feedback +Status: Open
 [2021-12-08 13:57 UTC]
Thanks for further input!

> From basic observation this seems to happen as soon as a second
> FastCGI php-cgi instance is started by IIS

Ah, right, something is wrong there.  I need to investigate.
 [2021-12-08 19:13 UTC]
-Status: Assigned +Status: Verified
 [2021-12-08 19:13 UTC]
It seems to me that the current tracing JIT implementation is
broken for any multiprocess Web SAPIs which *re*attach to OPcache
SHM (generally (F)CGI, but on Windows potentially any SAPI which
may run multiple PHP processes in parallel, unless they enforce
separate OPcache instances).  The problem begins in
zend_jit_trace_startup[1] where SHM memory is allocated for
zend_jit_traces and zend_jit_exit_groups, but that would be
reallocated whenever a new process attaches to OPcache SHM.  And
that appears to be the reason for the stack backtrace presented
above: where zend_jit_traces is not properly initialized to what
has been calculated previously, and as such causes a segfault.

That might be fixable without ABI break, but otherwise we should
make sure that tracing JIT is not available for such environments.

[1] <>
 [2021-12-08 19:30 UTC] alex at ndros dot com

I understand less than half of what you're saying, but it sounds just about right.

All I know is that PHP crashes instantly with jit, even by using a simple small php script.
 [2021-12-14 11:25 UTC]
-Assigned To: cmb +Assigned To:
 [2021-12-14 23:47 UTC]
The following pull request has been associated:

Patch Name: Fix #81679: Tracing JIT crashes on reattaching
On GitHub:
 [2021-12-15 14:35 UTC]
-Summary: PHP 8 opcache crashing when using JIT on Windows 2019 +Summary: Tracing JIT crashes on reattaching
 [2021-12-15 14:41 UTC]
Automatic comment on behalf of cmb69
Log: Fix #81679: Tracing JIT crashes on reattaching
 [2021-12-15 14:41 UTC]
-Status: Verified +Status: Closed
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jul 25 19:01:29 2024 UTC