[php-src] Issue #24445: Tracing JIT: a catch reads an int local as undefined after an internal call throws (8.4 regression)

Issue: https://github.com/php/php-src/issues/24445 Author: EJ-Research ### Description ### Description The following code: ```php <?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 <?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 ```plain 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