Tracing JIT: SIGSEGV via mis-targeted side-exit into execute_ex (VM-stack call-frame alloc), PHP 8.5.6

Description

Under production load, PHP-FPM workers reliably SIGSEGV with tracing JIT enabled. Disabling JIT (opcache.jit=disable) eliminates the crash entirely. The same code on the CLI SAPI (JIT off) never crashes, and the crashes began immediately upon upgrading from 8.1 to 8.5 (the 8.1 build, same application, never segfaulted).

The crash is intermittent and clusters: several workers die within a few minutes, then it goes quiet after an FPM restart flushes the JIT buffer, and recurs once the hot path is re-warmed.

Symbolized core analysis (matching php8.5-fpm-dbgsym, exact Build-Id 3ee70b5feebaea49aaae01c20bb6d0b372acb4dc):

• Kernel: php-fpm8.5: segfault at 2 ip <pc> error 6 in php-fpm8.5[...] — a user-mode write to address 0x2.
• Faulting PC = execute_ex + 16310, inside the inlined VM call-frame allocation fast path — it loads EG(vm_stack_top) / EG(vm_stack_end) from executor_globals (+0x1e0 / +0x1e8), computes a zval-sized bump (<< 4), and branches to the zend_vm_stack_extend slow path (jb -> execute_ex + 42820) when full.
• The recorded instruction pointer is mid-instruction (2 bytes into mov 0x1e8(%rcx),%rax), %rdx = 0x2 where a pointer is expected, frame #1 return address = 0x0, and gdb prints "Unable to read JIT descriptor from remote memory."

Interpretation: a tracing-JIT trace side-exit appears to return into execute_ex at a misaligned address with a clobbered register, so the VM-stack push-call-frame code dereferences/writes near-null → SIGSEGV. The combination of FPM-only (JIT on) vs CLI (JIT off) crashing, the regression appearing exactly at the 8.5 upgrade, the self-heal on JIT-buffer flush, and the broken/misaligned control flow all point at the tracing JIT rather than application logic or an extension (fault IP is in the core binary .text, not in any loaded .so).

Loaded extensions at crash time included opcache (compiled-in), redis, zip, xsl, xmlreader/writer, tokenizer, sysvshm (standard LAMP set). The triggering request was a question-rendering endpoint of a large PHP app (IMathAS).

The following code:

No minimal standalone reproducer yet — the crash only manifests inside a large
application's question-evaluation code path after the JIT hot threshold is reached.
A matching core dump + debug symbols are available, and I can run any requested
gdb commands against the core.

Resulting in this output:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  execute_ex + 16310   (inlined VM call-frame alloc: EG(vm_stack_top/end) bump)
#1  0x0000000000000000
rdx = 0x2 ; fault = user write to 0x2 ; recorded IP is mid-instruction
gdb: "Unable to read JIT descriptor from remote memory"

But I expected this output:

No crash (and indeed: with opcache.jit=disable there is no crash).

PHP Version

PHP 8.5.6 (fpm-fcgi, NTS), 8.5.6-3+ubuntu24.04.1+deb.sury.org+1 (deb.sury.org build)

Operating System

Ubuntu 24.04 (noble), x86-64. opcache.jit=tracing, opcache.jit_buffer_size=128M, opcache.memory_consumption=256, opcache.validate_timestamps=1, opcache.revalidate_freq=120.

Start with the supplied core dump and debug symbols, then inspect execute_ex around the VM-stack call-frame allocation and the zend_vm_stack_extend path. Use gdb to investigate the reported misaligned side-exit, clobbered register, null return address, and missing JIT descriptor. Done means identifying a reproducible tracing-JIT cause and verifying that the FPM crash no longer occurs without disabling JIT.