Segfault with tracing JIT on 2nd call of eval'd closure

Description

I keep running into this when attempting to benchmark PHP Handlebars. I reproduced the issue with two different laptops, one running Windows 11 (Intel Core Ultra 7 268V) and the other Ubuntu 24.04 (Intel Core i9-13900HX). I don't know if the processor matters, but those are the two I tested with.

To reproduce, check out https://github.com/devtheorem/php-handlebars/tree/segfault (the segfault branch), run composer install, then run the benchmark with 82 or more iterations:

php -d opcache.enable_cli=1 -d opcache.jit=tracing tests/benchmark.php 82

Output:

Compiled 82 times | 3.92 ms/compile | 22.6 KB code | 1.8 MB peak
Render 0...complete
Render 1...Segmentation fault

On line 88 of the tests/benchmark.php script, there is a warmup loop with 50 iterations to warm up the JIT before measuring compilation time. So it is actually on 132 or more total iterations (50 + 82) when the segmentation fault occurs. If this warmup loop is changed to only have 1 iteration rather than 50, then the script has to be run with a final argument of 131 or higher to trigger the segmentation fault.

But if the warmup loop is removed, or its body replaced with simply strlen("warmup");, then the segfault never occurs, no matter how many iterations the benchmark runs with. So somehow having this preliminary loop with the same function calls as the loop following it causes a segfault later the second time that the $renderer closure is invoked.

Please let me know if anything more is needed to reproduce the issue. On Ubuntu, a "Sorry, the application php8.5 has stopped unexpectedly" popup is shown which has more details and a stacktrace:

PHP Version

PHP 8.5.5 (cli) (built: Apr  7 2026 19:24:35) (NTS Visual C++ 2022 x64)
Copyright (c) The PHP Group
Built by The PHP Group
Zend Engine v4.5.5, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.5, Copyright (c), by Zend Technologies

Operating System

Windows 11, Ubuntu 24.04

can reproduce I believe

UBSAN_OPTIONS=print_stacktrace=1 ../sapi/cli/php -d opcache.enable_cli=1 -d opcache.jit=tracing tests/benchmark.php
Compiled 1000 times  |  45.20 ms/compile  |    22.6 KB code    |  2.2 MB peak
Render 0...complete
Render 1.../home/dcarlier/Contribs/php-src/Zend/zend_types.h:1414:9: runtime error: member access within misaligned address 0x000000000019 for type 'zend_refcounted' (aka 'struct _zend_refcounted'), which requires 4 byte alignment
0x000000000019: note: pointer points here
<memory cannot be printed>
    #0 0x556b2e6e7523 in zval_addref_p /home/dcarlier/Contribs/php-src/Zend/zend_types.h:1414:9
    #1 0x556b2e33a348 in ZEND_SEND_VAR_EX_SPEC_CV_UNUSED_QUICK_TAILCALL_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:107477:3
    #2 0x556b2daa32fe in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:116202:12
    #3 0x556b2daa537e in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:121914:2
    #4 0x556b2ecc968f in zend_execute_script /home/dcarlier/Contribs/php-src/Zend/zend.c:1977:3
    #5 0x556b2d17f004 in php_execute_script_ex /home/dcarlier/Contribs/php-src/main/main.c:2641:13
    #6 0x556b2d180248 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2681:9
    #7 0x556b2ecdaeb2 in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:951:5
    #8 0x556b2ecd6e91 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1362:18
    #9 0x7f6b56678f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #10 0x7f6b56679026 in __libc_start_main csu/../csu/libc-start.c:360:3
    #11 0x556b29007e30 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x3807e30) (BuildId: 08e02d614fb7944e98494e249267ce0f908ba00c)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/dcarlier/Contribs/php-src/Zend/zend_types.h:1414:9

With the current feature branch I've been working on, I'm now running into this segfault even without any warmup or measurement loops in the benchmark. After just a single compilation, the segfault occurs on the second call to the eval'd closure. I pushed a new segfault2 branch demonstrating this, and again reproduced it on both Windows and Ubuntu.

https://github.com/devtheorem/php-handlebars/tree/segfault2

To reproduce check out the branch, run composer install, and then run:

php -d opcache.enable_cli=1 -d opcache.jit=tracing tests/benchmark.php

I've been trying to make a more minimal reproduction, and ran into a case where rather than a segmentation fault occurring, a function is incorrectly called with an integer (apparently a heap pointer?) rather than a Closure, causing a PHP TypeError.

I added a reproduction script to my segfault2 branch mentioned above, which can be run via:

php -d opcache.enable_cli=1 -d opcache.jit=tracing tests/jit_type_error.php

Last 10 lines of output:

Render 58...OK
Render 59...OK
Render 60...OK
Render 61...
Fatal error: Uncaught TypeError: LR::hbbch(): Argument #2 ($cb) must be of type ?Closure, int given, called in C:\code\GitHub\php-handlebars\tests\jit_crash_code.php on line 15 and defined in C:\code\GitHub\php-handlebars\tests\jit_type_error.php:17
Stack trace:
#0 C:\code\GitHub\php-handlebars\tests\jit_crash_code.php(15): LR::hbbch(Array, 2353254736256)
#1 C:\code\GitHub\php-handlebars\tests\jit_type_error.php(52): {closure:C:\code\GitHub\php-handlebars\tests\jit_crash_code.php:2}()
#2 {main}
  thrown in C:\code\GitHub\php-handlebars\tests\jit_type_error.php on line 17

Notice that on Render 61, the second argument to hbbch() was changed to a large integer rather than a Closure like is actually stored in the passed $g variable. Every time I run the script, the specific value of this integer changes (e.g. 2109548896640, 1896625054080, 2234430103936).

If I run the script without the tracing JIT (e.g. php tests/jit_type_error.php) it completes without any errors.

Interestingly, neither the segfault nor the TypeError occur with PHP 8.4, so it seems that the issue must have been introduced in master after PHP 8.4 entered feature freeze.

With the help of an LLM agent, I added various print statements to the OPcache JIT code, and then ran my jit_type_error.php script to generate a debug log of the JIT state during its execution. The LLM then read this log and identified "missing runtime IR guards before unconditional scalar writes" as the bug, and created a patch which does seem to resolve the issue for me (the segfault and TypeError no longer occur after building PHP 8.5 with this patch): theodorejb@fb6e58b

I also asked the agent to compare the differences in the JIT code between the PHP-8.4 and PHP-8.5 branches, to find which commit started the problem. The LLM identified 097edc8 as introducing the issue, though I haven't tried building PHP before/after this specific commit to confirm.

I'm not familiar enough with the JIT code to know whether the above patch is the right approach for fixing the issue, so I'm hesitant to open a PR unless someone more knowledgeable than me thinks the patch and commit message look okay.

I kept whittling away at the jit_type_error.php script, until I got it down to a much more minimal reproduction which doesn't depend on any package code:

<?php
final class LR {
    public static function p(mixed $cx, string $name, mixed $context, array $hash, string $indent): string {
        try { $result = ''; } finally {}
        $lines = explode("\n", $result);
        foreach ($lines as $i => $_) { if ($i === 0) break; }
        return $result;
    }
    public static function hbbch(array $positional, ?\Closure $cb): string {
        if ($cb && is_array($positional[0] ?? null)) foreach ($positional[0] as $v) $cb($v);
        return '';
    }
}

$renderCode = <<<'PHP'
<?php
return function (mixed $in = null, array $options = []) {
 $a = null;
 $b = '';
 $c = '';
 $d = fn() => '';
 $e = fn() => '';
 $f = fn() => '';
 $g = fn() => '';
 return ''
  .LR::p(null, '', null, [], '')
  .LR::hbbch([null], $d)
  .LR::hbbch([null], $e)
  .LR::hbbch([null], $f)
  .LR::hbbch([null], $g);
};
PHP;

$renderFile = __DIR__ . '/jit_crash_code.php';
file_put_contents($renderFile, $renderCode);
$renderer = require $renderFile;

for ($r = 0; $r < 70; $r++) {
    echo "Render $r...";
    $renderer();
    echo "OK\n";
}

echo "--- Completed without crash (JIT may not have been active) ---\n";

Running this via php -d opcache.enable_cli=1 -d opcache.jit=tracing jit_type_error.php results in an unexpected TypeError after the $renderer closure is invoked 61 times. I updated the patch linked in my previous comment to include this test case.

Fix incorrect trace stop type

@theodorejb

Thank you @theodorejb!

Navigation Menu

Repository navigation

Segfault with tracing JIT on 2nd call of eval'd closure #21746

Description

PHP Version

Operating System

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segfault with tracing JIT on 2nd call of eval'd closure #21746

Description

Description

PHP Version

Operating System

Activity

devnexen commented on Apr 14, 2026

theodorejb commented on Apr 16, 2026

theodorejb commented on Apr 17, 2026

theodorejb commented on Apr 19, 2026

theodorejb commented on Apr 20, 2026

arnaud-lb commented on May 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions