Bug #81679 [Com]: PHP 8 opcache crashing when using JIT on Windows 2019

From: Date: Wed, 08 Dec 2021 19:30:27 +0000
Subject: Bug #81679 [Com]: PHP 8 opcache crashing when using JIT on Windows 2019
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-238290@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81679&edit=1 ID: 81679 Comment by: alex at ndros dot com 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 Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2021-12-01 11:03:22] cmb@php.net 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] <https://bugs.php.net/bugs-generating-backtrace-win32.php> ------------------------------------------------------------------------ [2021-11-30 22:50:49] alex at ndros dot com This seem to happen to any PHP application. ------------------------------------------------------------------------ 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

« previous php.bugs (#238290) next »