Bug #81679 [PATCH]: PHP 8 opcache crashing when using JIT on Windows 2019
Edit report at https://bugs.php.net/bug.php?id=81679&edit=1
ID: 81679
Patch added by: cmb@php.net
Reported by: alex at ndros dot com
Summary: PHP 8 opcache crashing when using JIT on Windows
2019
Status: Verified
Type: Bug
Package: JIT
Operating System: Windows Server 2019
PHP Version: 8.0.13
Block user comment: N
Private report: N
New Comment:
The following pull request has been associated:
Patch Name: Fix #81679: Tracing JIT crashes on reattaching
On GitHub: https://github.com/php/php-src/pull/7776
Patch: https://github.com/php/php-src/pull/7776.patch
Previous Comments:
------------------------------------------------------------------------
[2021-12-14 14:30:43] cmb@php.net
Related To: Bug #81664
------------------------------------------------------------------------
[2021-12-08 19:30:27] alex at ndros dot com
HI cmb@php.net!
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-08 19:13:59] cmb@php.net
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] <https://github.com/php/php-src/blob/php-8.0.13/ext/opcache/jit/zend_jit_trace.c#L51>
------------------------------------------------------------------------
[2021-12-08 13:57:54] cmb@php.net
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 12:16:49] 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]
0x00001000`080005cb
0x0000025d`00000003
0x0000009f`445fb630
0x0000025d`9d753e00
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
------------------------------------------------------------------------
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=81679
--
Edit this bug report at https://bugs.php.net/bug.php?id=81679&edit=1
Thread (9 messages)