When a recursive call happens with invalid arguments, the maximum valid
arguments are computed and stored in `num_args`, but the RECV entry
block we jump to is `call_num_args` instead. This can skip argument
validation checks. Fix this by using `num_args` instead.
Closes GH-16575.
This happens because on ZTS we execute `executor_globals_ctor` which reset the
`freelist` and `p5s` pointers, while on NTS we don't.
On NTS we can reuse the caches but on ZTS we can't, the easiest fix is
to call `zend_shutdown_strtod` when preloading is shut down.
This regressed in GH-13974 and therefore only exists in PHP 8.4 and
higher.
Closes GH-16602.
zend_jit() assumes that Closure op_arrays have no scope, but this is not true
when using the hot counters, first exec, or trace triggers as they use the
executed op_array, which is in case of Closures is a copy, with a scope.
In the tracing JIT this problem is avoided as we fetch the original op_array
when compiling a Closure. Here I replicate this for the hot counters and first
exec triggers.
Fixes GH-16186
Closes GH-16200
Now it's possible that PHP tracing JIT loses some parts of the "hot"
code. In case we have a root LOOP trace with an inlined call of some
function, and we get a SIDE exit inside that function - we recorded a
side trace, but finished it a the RETURN of the inlined function. As
result the opcodes betwee RETURN from SIDE trace and LOOP exit were not
covered by tracer and were executed in interpreter.
This patch introduces a "ret_depth" argument that prevents stopping
tracing on RETURN of such SIDE trace.
The frameless function handlers do not update the op variables when
handling the result is undefined. In this case this causes propagating
an UNDEF value into a temporary, which results in an extra undefined
variable warning for a temporary in this case.
The original issue also reports a crash in some cases, which is also
fixed by this patch.
Closes GH-16012.
regressing commit: 654b787ee1
This was called if JIT was enabled or not. If not enabled, it'll result
in an undeclared function warning and maybe a bad time in the linker.
Gate the meat of this PHP-side function on if JIT is enabled (but keep
it existing so PHP userland code works with or without JIT, OFC).
Internally accessible via zend_jit_blacklist_function / externally via opcache_jit_blacklist.
The functionality currently only affects tracing JIT, but may be extended to other JIT modes in future.
zend_get_property_info_for_slot(obj, slot) assumes that 'slot' belongs to 'obj', but that may not be the case for lazy proxies.
Fortunately, the property info is often already available in path when it is needed.
For other cases, I make zend_get_property_info_for_slot() aware of lazy objects, and add zend_get_property_info_for_slot_self() for cases where the 'slot' is known to belong to the object itself.
Fixes oss-fuzz #71446
There are two related issues, each tested.
First problem:
What happens is that on the CLI SAPI we have a per-request pcre cache,
and on there the request shutdown for the pcre module happens prior to
the remaining live object destruction. So when the SPL object wants to
clean up the regular expression object it gets a use-after-free.
Second problem:
Very similarly, the non-persistent resources are destroyed after request
shutdown, so on the CLI SAPI the pcre request cache is already gone, but
if a userspace stream references a regex in the pcre cache, this breaks.
Two things that come immediately to mind:
- We could fix it by no longer treating the CLI SAPI special and just use
the same lifecycle as the module. This simplifies the pcre module code
a bit too. I wonder why we even have the separation in the first place.
The downside here is that we're using more the system allocator
than Zend's allocator for cache entries.
- We could modify the shutdown code to not remove regular expressions
with a refcount>0 and modify php_pcre_pce_decref code such that it
becomes php_pcre_pce_decref's job to clean up when the refcount
becomes 0 during shutdown. However, this gets nasty quickly.
I chose the first solution here as it should be reliable and simple.
Closes GH-15064.
The crash happens because the zend_persist.c code tries to JIT the hook's
op_array while the JIT buffer memory is still protected. This happens in
`zend_persist_property_info` called via `zend_persist_class_entry`
through the inheritance cache.
We shouldn't JIT the property hook code when persisting property info
for the inheritance cache.
This is a simple workaround by temporarily disabling the JIT so that the
property hook code is not JITted when persisting the property info.
An alternative solution would be to move the JITting of the property
hooks to a different place in zend_persist.c by doing an additional pass
over the classes.
Closes GH-15819.
