In SCCP, arrays containing partial objects must be marked as partial so that
their values are not accidentally propagated.
Fixes GH-21227
Closes GH-21232
The SysV shared memory allocator in OPcache hardcodes a maximum segment size of
32MB (SEG_ALLOC_SIZE_MAX). If the JIT buffer exceeds this, which it does with
the default 64MB size, startup will fail with "Insufficient shared memory!".
The allocator will now try allocating a contiguous buffer first, and only then
use segmentation by searching for continuously smaller powers of 2.
Fixes GH-20718
Closes GH-20719
When FE_RESET_RW executes, it converts the CV to a reference before
checking if the array/object is empty. However, when the JIT creates
exit points for FE_RESET_RW in zend_jit_trace_handler(), it wasn't
updating the stack type for op1 to reflect this change.
This caused side traces compiled from these exit points to have
incorrect type information. The side trace's CV cleanup code would
see IS_OBJECT and generate a direct call to zend_objects_store_del(),
but the actual value was a zend_reference*, causing a segfault.
The fix adds ZEND_FE_RESET_RW to the list of opcodes that temporarily
set their op1 stack type to IS_UNKNOWN before creating exit points.
This follows the same pattern used for ZEND_BIND_INIT_STATIC_OR_JMP.
When IS_UNKNOWN, the JIT falls back to SSA type info which correctly
includes MAY_BE_REF for FE_RESET_RW's op1_def.
Fixes GH-20818
Closes GH-20948
This is similar to f6c2e40a11 but for minimal JIT + tracing JIT.
Most of the times the tracing JIT shouldn't rely on going to the VM, but
in some cases, like in minimal JIT, it can and then it hits the same
bug.
Closes GH-20897.
* Fix use-after-free in FE_FREE with GC interaction
When FE_FREE with ZEND_FREE_ON_RETURN frees the loop variable during
an early return from a foreach loop, the live range for the loop
variable was incorrectly extending past the FE_FREE to the normal
loop end. This caused GC to access the already-freed loop variable
when it ran after the RETURN opcode, resulting in use-after-free.
Fix by splitting the ZEND_LIVE_LOOP range when an FE_FREE with
ZEND_FREE_ON_RETURN is encountered:
- One range covers the early return path up to the FE_FREE
- A separate range covers the normal loop end FE_FREE
- Multiple early returns create multiple separate ranges
* Split the live-ranges of loop variables again
b0af9ac733 removed the live-range splitting of foreach variables, however it only added handling to ZEND_HANDLE_EXCEPTION.
This was sort-of elegant, until it was realized in 8258b7731b that it would leak the return variable, requiring some more special handling.
At some point we added live tmpvar rooting in 52cf7ab8a2, but this did not take into account already freed loop variables, which also might happen during ZEND_RETURN, which cannot be trivially accounted for, without even more complicated handling in zend_gc_*_tmpvars() functions.
This commit also proposes a simpler way of tracking the loop end in loopvar freeing ops: handle it directly during live range computation rather than during compilation, eliminating the need for opcache to handle it specifically.
Further, opcache was using live_ranges in its basic block computation in the past, which it no longer does. Thus this complication is no longer necessary and this approach should be actually simpler now.
Closes#20766.
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
---------
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
Co-authored-by: Gustavo Lopes <mail@geleia.net>
In the following optimization:
JMPZ(X,L1) JMP(L2) L1: -> JMPNZ(X,L2) NOP
L1 must not be followed by another block, so that it may safely be followed by
the block containing the JMPNZ. get_next_block() is used to verify L1 is the
direct follower. This function also skips empty blocks, including live, empty
target blocks, which will then implicitly follow the new follow block. This will
result in L1 being followed by two separate blocks, which is not possible.
Resolve this by get_next_block() stopping at target blocks.
Fixes OSS-Fuzz #472563272
Closes GH-20850
As far as I can tell that's been there since the initial open source
release (commit 528006a). The header defines ftok() and a handful of
IPC_* constants, none of which are used here.
System V IPC is increasingly being replaced by POSIX IPC and may
therefore not be implemented on new and/or hobbyist operating systems
such as SerenityOS[1]. In the past that wasn't an issue as the OPCache
could be disabled, which is no longer possible as of PHP 8.5[2].
I was able to build with the include patched out, but we would prefer
this to be addressed upstream.
1: https://github.com/SerenityOS/serenity/pull/26465
2: https://github.com/php/php-src/pull/18961
Strings loaded from the file cache can not have a CE cache, because their cache
slot is invalid. Remove the IS_STR_CLASS_NAME_MAP_PTR flag from these strings.
We can also avoid updating the str flags in SERIALIZE_STR(), since the same
updates must also be done in UNSERIALIZE_STR().
This was already done for interned strings, but not for non-interned ones.
Fixes GH-20329
Closes GH-20337
The offset becomes stale if the environment changes. We're currently relying on
other factors in the environment staying constant, e.g. send types. But this
seems to be the worst offender.
Partially addresses GH-17733
Closes GH-20328
The dynamic loader, starting around version 1284, patches the thunk emitted for
thread local variables by the compiler, so that its format changes from
struct Thunk {
void *func;
size_t module;
size_t offset;
}
to
struct Thunk_v2 {
void *func;
uint32_t module;
uint32_t offset;
// other fields
}
which has the same size, but not the same layout.
This is mentionned in
9307719dd8/libdyld/ThreadLocalVariables.h (L90)
As a result, access to thread specific variables in JIT is broken.
Fix by using the new layout when the new dynamic loader is in use.
Closes GH-20121
preload_load() reads EG(class_table) and EG(function_table), but these may not
be initialized. Move these accesses out of preload_load().
Closes GH-20081
zend_runtime_jit() prevents concurrent compilation with
zend_shared_alloc_lock(), but this doesn't prevent blocked threads from
trying to compile the function again after they acquire the lock.
In the case of GH-19889, one of the function entries is compiled with
zend_jit_handler(), which fails when the op handler has already been replaced by
a JIT'ed handler.
Fix by marking compiled functions with a new flag ZEND_FUNC_JITED, and
skipping compilation of marked functions. The same fix is applied to
zend_jit_hot_func().
Fixes GH-19889
Closes GH-19971
Both processes race to compile warning_replay.inc. Whichever is first will get
to persist the script. The loser will use the script that is already persisted,
and the script that was just compiled is freed.
However, EG(errors) and persistent_script->warnings still refer to the same
allocation, and EG(errors) becomes a dangling pointer. To solve this, we simply
don't free warnings from free_persistent_script() anymore to maintain exclusive
ownership for EG(errors).
Furthermore, we need to adjust a call to zend_emit_recorded_errors() that would
previously use EG(errors), even when persistent_script has been swapped out.
Fixes GH-19984
Closes GH-19995
