* remove `libmysqlclient_with_mysqli` support from nightly workflow
* remove `libmysqlclient_with_mysqli` support from root workflow
* remove `withMysqli` support from `build-libmysqlclient` action
* remove `withMysqli` support from `test-libmysqlclient` action
* in root workflow, drop code checking for PHP 8.1
[skip ci]
In a lot of places the return value is not checked, and when the
function fails the code continues execution. However, this means that
operations on the stack fail and will cause memory leaks on the objects
that weren't pushed.
We also notice an inconsistency in how these failures are handled.
For example, in one place we explicitly have a fatal error
`php_error_docref(NULL, E_ERROR, "Memory allocation failure");`
but this is the only place to do so.
Closes GH-20957.
The computed number of properties using zend_hash_num_elements(zobj->properties)
is incorrect when the object contains virtual properties. We don't have a
trivial way to find the number of properties virtual properties that need to be
added to this number, so just append with zend_hash_add_new() instead.
Fixes GH-20479
Closes GH-20988
This test still fails on i386 Windows with "Allowed memory size of %d bytes
exhausted" because the output buffer grows too big. My first intuition was to
add a chunk_size to ob_start, but this won't work if the output buffer is
flushed deep into the call stack, causing a premature or just a second stack
limit error. So, reduce the stack size in an attempt to produce less output.
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.
When __clone of the underlying object fails with a bailout, ZEND_ASSERT(res ==
SUCCESS) in zend_lazy_object_del_info() will fail because the info has not been
registered yet.
Only copy OBJ_EXTRA_FLAGS once the info has been successfully registered.
Fixes GH-20905
Closes GH-20975
- Remove unnedded putenv('NO_INTERACTION=1') when executing individual tests.
- Fix undefined variable errors when executing individual tests.
- Fix -s when NO_INTERACTION=1 is set, given we don't need to prompt anyway.
Fixes GH-20961
Closes GH-20970
Within hooks, the backing value can directly be accessed as if no hooks were
present. This was previously handled only in read_property().
zend_fetch_property_address(), which is used for by-ref assignment, will first
call get_property_ptr_ptr() and then try read_property(). However, when called
on uninitialized backing values, read_property() will return
&EG(uninitialized_zval) with an uninitialized property warning. This is
problematic for zend_fetch_property_address() because it write to the result of
read_property() unless there's an exception.
For untyped properties, this can result in writes to &EG(uninitialized_zval)
(see oss-fuzz-471486164-001.phpt). For types properties, it will result in an
unexpected "Typed property C::$prop must not be accessed before initialization"
exception.
Fixes OSS-Fuzz #471486164
Closes GH-20943
This can trigger the memory limit in run-tests.php, which buffers the tests
output. Instead, only output "nesting level too deep" and discard the rest.
Closes GH-20946
* 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>
