Skip to content

Tracing JIT calls the wrong method for self::/parent:: static calls in trait methods shared by several classes #23572

Description

@RV7PR

Description

With the tracing JIT, a trait method that calls self::x() or parent::x() is compiled with the callee resolved from the class that was executing when the trace was recorded. All classes using the trait share the same opcodes and therefore the same trace, but no callee guard is emitted when the resolved class is in the same file. The other classes then silently call the first class's method. No exception, no crash, just a wrong result.

<?php
class ParentA { public static function m() { return 'A'; } }
class ParentB { public static function m() { return 'B'; } }

trait T {
    public function run(string $s) {
        return parent::m() . $s;
    }
}

class A extends ParentA { use T; }
class B extends ParentB { use T; }

$a = new A;
$b = new B;

$a->run('x');
$a->run('x');
$a->run('x');
echo $a->run('x'), "\n";
echo $b->run('y'), "\n";
echo $b->run('y'), "\n";
echo $a->run('x'), "\n";
php -d opcache.enable_cli=1 -d opcache.jit=tracing -d opcache.jit_buffer_size=16M \
    -d opcache.jit_hot_func=2 -d opcache.jit_hot_loop=255 -d opcache.jit_hot_return=255 \
    -d opcache.jit_hot_side_exit=255 test.php

Resulted in this output:

Ax
Ay
Ay
Ax

But I expected this output instead:

Ax
By
By
Ax

Without JIT and with opcache.jit=function the output is correct. The same happens with self:: (self::n() where A::n() and B::n() are declared in the using classes). The small hot counters only make it reproduce quickly; with defaults it happens once the trait method becomes hot.

The trace log (opcache.jit_debug=0x3F000) shows a single trace recorded for A::run() and no exit at all when B::run() executes:

---- TRACE 1 start (enter) A::run() test.php:6
---- TRACE 1 stop (return)
---- TRACE 1 compiled
Ax
Ay
Ay
Ax

Analysis

In zend_jit_init_static_method_call() (ext/opcache/jit/zend_jit_ir.c) the class for self::/parent:: comes from zend_get_known_class(), which uses op_array->scope. For a trait clone that is the scope of the recording class (here A), so func becomes ParentA::m. zend_jit_may_be_modified() then returns false because ParentA is declared in the same file, so no guard is emitted and ParentA::m is baked into the trace. B::run() reuses the trace through the shared opcodes.

The DO_FCALL side already handles this case (zend_jit_do_fcall(), "megamorphic call from trait"), and zend_jit_trace.c refuses to skip the guard for fake INIT calls of trait clones with a non-CONST class operand, but the INIT side of a recorded static call does not.

Dropping the static resolution for trait clones with a non-CONST class operand, right after zend_get_known_class(), makes the existing code emit the callee guard with a plain side exit, after which B::run() gets its own trace:

	ce = zend_get_known_class(op_array, opline, opline->op1_type, opline->op1);
	if ((op_array->fn_flags & ZEND_ACC_TRAIT_CLONE) && opline->op1_type != IS_CONST) {
		ce = NULL; func = NULL; call_info = NULL; /* megamorphic call from trait */
	}

With that change both variants produce the expected output on master, and ext/opcache/tests/jit passes (487/0 on master, macOS arm64). A phpt covering self:: and parent:: is ready (init_static_method_call_002.phpt); I can open a PR against PHP-8.5 if this approach is acceptable, or leave the fix to you if a polymorphic side trace is preferred.

The parent::-in-a-trait pattern is also the trigger for the 8.5 reports in #17626 (see #23571): there the guard is only emitted because a grandparent lives in another file, and it is the failure of that guard that reaches the bug fixed by #23571.

Disclaimer

The analysis and the suggested patch were produced with Claude Fable 5.1 (Anthropic) at my direction; I ran the reproductions and test runs on my machine and verified the results, but I cannot review the C myself.

PHP Version

PHP 8.5.10 (built from the php-8.5.10 tag) and master (1053403). PHP 8.4.26-dev gives the correct output; the resolving code in zend_jit_init_static_method_call() exists since 8.5.

Operating System

macOS 15 (arm64); not OS specific.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions