Tracing JIT: a catch reads an int local as undefined after an internal call throws (8.4 regression)

Start with the OPcache tracing JIT and register allocation paths implicated by the issue, then read the related issue #24186 for context. Reproduce using the supplied PHP script and tracing JIT command; compare the exception path with side exits, checking whether the local is written back before the catch runs. Done means the catch reads the assigned value correctly under tracing JIT while the supplied comparison modes remain correct.

Description

Description

The following code:

<?php
function loop(array $p): void { foreach ($p as $v) {} }
function id(int $n): int { return $n; }
function run(array $p, int $d): int {
    loop($p);
    $n = count($p);
    try {
        intdiv(1, $d);
    } catch (DivisionByZeroError $e) {
        var_dump($n);
        return -1;
    }
    return id($n);
}
for ($i = 0; $i < 200; $i++) {
    run([1], 1);
}
run([1], 0);

run with OPcache as the only extension:

php -n -d zend_extension=opcache -d opcache.enable_cli=1 -d opcache.jit=tracing -d opcache.jit_buffer_size=64M -d opcache.file_update_protection=0 test.php

Resulted in this output:

Warning: Undefined variable $n in /up/test.php on line 10
NULL

But I expected this output instead:

int(1)

$n is assigned before the try and nothing touches it afterwards, yet the catch block sees it as undefined once the tracing JIT has compiled run()

Some more details:

• opcache.jit=1254, 1255 and 1154 give the same wrong output. 1054 (tracing without register allocation), function and disable all print int(1)
• PHP 8.3.35 and 8.2.33 print int(1) with the same command in tracing, 1254, 1255, function and disable mode. We checked with opcache_get_status() that the JIT was on and had compiled code, so this looks like a regression in 8.4
• With the default hot counters it takes 135 warm-up calls to trigger it; with 130 the script still prints int(1). With -d opcache.jit_hot_loop=1 -d opcache.jit_hot_func=1, 10 calls are enough
• opcache.file_update_protection=0 is only there because OPcache does not cache a script written less than 2 seconds earlier, which would hide the bug when the file has just been created

If $n is an int parameter that the function assigns again, the catch block does not see it as undefined but reads the parameter's old value, without any warning:

<?php
function loop(array $p): void { foreach ($p as $v) {} }
function id(int $n): int { return $n; }
function run(array $p, int $d, int $n = 5): int {
    loop($p);
    $n = count($p);
    try {
        intdiv(1, $d);
    } catch (DivisionByZeroError $e) {
        var_dump($n);
        return -1;
    }
    return id($n);
}
for ($i = 0; $i < 200; $i++) {
    run([1], 1);
}
run([1], 0);

This prints int(5) with the tracing JIT on 8.4.18, and int(1) with the function JIT and on 8.3.35 and 8.2.33

What changes the result

Starting from the first script, we changed one thing at a time and ran it with the tracing JIT on 8.4.18. Where $n is not an int, id() and run() were changed to take and return mixed

• Removing the loop($p) call, or the foreach inside loop(), makes it print int(1)
• Replacing return id($n); with return 0;, so that only the catch block reads $n, also makes it print int(1)
• A float ($n = count($p) + 0.5) and an int returned by an internal function ($n = hrtime(true)) are lost in the same way. A bool, a string or an array (count($p) > 0, str_repeat('a', count($p)), [count($p)]) is kept
• An internal method behaves like intdiv(): $it->seek($d) on an ArrayIterator, with the last call passing 9 so that it throws OutOfBoundsException, loses $n as well. With a condition on $d in the argument, $it->seek($d === 0 ? 9 : 0), $n is kept
• If the exception comes from a user function instead, either one that throws DivisionByZeroError itself or one that calls intdiv(), $n is kept

What the JIT does

With opcache.jit_debug=0x1C0000 on 8.4.18, the call that throws runs in a trace that starts where loop() returns:

---- TRACE 5 TSSA start (return) run() /up/test.php:6
0005 #5.T4 [long] RANGE[MIN..MAX] = COUNT #0.CV0($p) [!rc1, rcn, array of [any, ref]] ; op1(packed array)
0006 ASSIGN #2.CV2($n) [!undef] -> #6.CV2($n) [long] RANGE[MIN..MAX] #5.T4 [long] RANGE[MIN..MAX] ; op1(undef) op2(int)
0007 INIT_FCALL 2 112 string("intdiv")
0008 SEND_VAL int(1) 1
0009 SEND_VAR #1.CV1($d) [!long] -> #7.CV1($d) [long] 2 ; op1(int)
0010 DO_ICALL
---- TRACE 5 exit info
     exit_2: 0007/0005/5/VM CV0($p):array CV2($n):int(rbx) X4:int
     exit_3: 0009/0010/5/CALL CV0($p):array CV2($n):int(rbx) X4:int
     exit_4: 0011/0015/5/VM CV0($p):array CV1($d):int CV2($n):int(rbx) X4:int
     exit_5: 0017/0020/5/VM CV0($p):array CV1($d):int CV2($n):int(rbx) X4:int

$n is held only in rbx, and the exit info shows that every side exit after the assignment knows this. When intdiv() throws inside the trace, though, the catch block (run by the VM) finds the slot of $n still undefined. It looks as if the exception path out of the trace does not write rbx back to the slot of $n, the way a side exit would. In the parameter variant the slot still holds the earlier value, the default 5, which is why the catch block reads a stale value there instead of an undefined one

This may be related to #24186, where a value held only in a register is lost when a tracing JIT loop exits to handle an interrupt

How we found it

We hit this in a long-running Swoole server that uses opcache.preload with the tracing JIT. A catch block passed such an int to a function with an int parameter, so a TypeError was thrown instead of the original PDOException. Our application then did not see that the database connection had died, kept reusing it, and every request on it failed until the connection was recycled. In our application the bug only showed with preload, while the scripts above do not need it. We worked around it by computing the value again inside the catch block

PHP Version

PHP 8.4.18 (cli) (built: Feb 13 2026 18:37:49) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.18, Copyright (c), by Zend Technologies

Also reproduced on 8.4.26, the latest 8.4 release (NTS, x86_64). Not reproduced on 8.3.35 or 8.2.33 (the docker-library php:8.3-cli and php:8.2-cli images)

PHP Version

PHP 8.4.18 (cli) (built: Feb 13 2026 18:37:49) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.18, Copyright (c), by Zend Technologies

Operating System

Alpine Linux v3.23 on x86_64 for 8.4.18, and Debian GNU/Linux 13 (trixie) on x86_64 for 8.3.35 and 8.2.33, all in Docker