[arnaud-lb]

zend_jit_trace_find_init_fcall_op() tries to find the INIT_FCALL opline corresponding to a ZEND_JIT_TRACE_INIT_CALL record, but it fails to do so in the ZEND_JIT_TRACE_FAKE_INIT_CALL case, for nested calls.

The ZEND_JIT_TRACE_FAKE_INIT_CALL case implies that p points to a sequence of ZEND_JIT_TRACE_INIT_CALL trace records. The first loop in zend_jit_trace_find_init_fcall_op() is supposed to find the first opline after the sequence, but it mistakenly decrements p after initially incrementing it. As a result p eventually points to an invalid record.

It works for non-nested calls because the p->op == ZEND_JIT_TRACE_VM condition is true on the first iteration in that case.

This can not lead to a crash or miscompilations, but this results in lost optimization opportunities.

[iliaal]

Direction fix looks right: the pre-loop p++ sets up the forward scan and the trailing p-- undid it, so anything other than the innermost fake INIT_CALL ended up walking backward and returning NULL. call_level comes out correct for each position in the chain once it goes forward (2/1/0 for an A -> B -> C pending chain).

It is wider than just num_args though: init_opline going non-NULL also enables the NO_NEED_RELEASE_THIS / ALWAYS_RELEASE_THIS assignment for chained fake records, which previously fell through. That looks fine to me, ZEND_NEW always sets ZEND_CALL_RELEASE_THIS (zend_vm_def.h:6058) and both method-call arms exclude fake records, but it is more than the subject suggests.