The check called an API only available with this def set.
Gate the check behind ifdef and change control flow to better fit it.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
These tests are failing because the integers are too large to be cast
to a PHP int. We fix this by expecting either an int or a string.
Closes GH-16278.
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
The behaviour is weird in the sense that the reference must get
unwrapped. What ended up happening is that when destroying the old
reference the sources list was not cleaned properly. We add handling for
that. Normally we would use use ZEND_TRY_ASSIGN_STRINGL but that doesn't
work here as it would keep the reference and change values through
references (see bug #26639).
Closes GH-16272.
In the test, I have an internal `__call` function for `_ZendTestMagicCallForward` that calls the global function with name `$name` via `call_user_function`.
Note that observer writes the pointer to the previously observed frame in the last temporary of the new call frame (`*prev_observed_frame`).
The following happens:
First, we call `$test->callee`, this will be handled via a trampoline with T=2 for the two arguments. The call frame is allocated at this point. This call frame is not observed because it has `ZEND_ACC_CALL_VIA_TRAMPOLINE` set. Next we use `ZEND_CALL_TRAMPOLINE` to call the trampoline, this reuses the stack frame allocated earlier with T=2, but this time it is observed. The pointer to the previous frame is written outside of the call frame because `T` is too small (should be 3). We are now in the internal function `_ZendTestMagicCallForward::__call` where we call the global function `callee`. This will push a new call frame which will overlap `*prev_observed_frame`. This value gets overwritten by `zend_init_func_execute_data` when `EX(opline)` is set because `*prev_observed_frame` overlaps with `EX(opline)`. From now on, `*prev_observed_frame` is corrupted. When `zend_observer_fcall_end` is called this will result in reading wrong value `*prev_observed_frame` into `current_observed_frame`. This causes issues in `zend_observer_fcall_end_all` leading to the segfault we observe.
Despite function with `ZEND_ACC_CALL_VIA_TRAMPOLINE` not being observed, the reuse of call frames makes problems when `T` is not large enough.
To fix this, we make sure to add 1 to `T` if `ZEND_OBSERVER_ENABLED` is true.
Closes GH-16252.
The prepared statement emulation layer is handling binary content in a
way that creates warnings in MySQL.
When analysing the query logs, we saw that the content sent to the
server is missing `0x5C` characters when the using emulated prepares.
This introduces a minimal test case that reproduces the issue to aid the
solution.
More info: https://github.com/doctrine/dbal/pull/6522#issuecomment-2340939347
Signed-off-by: Luís Cobucci <lcobucci@gmail.com>
There are three connected subtle issues:
1) The fast path didn't correctly handle the case where the decoder
requests more data. This caused a bogus additional replacement
sequence to be outputted when encountering an incomplete sequence at
the edges of a buffer.
2) The finishing of decoding incorrectly assumed that the fast path
cannot be in a state where the last few bytes were an incomplete
sequence, but this is not true as shown by test 08.
3) The finishing of decoding could output bytes twice because it called
into dom_process_parse_chunk() twice without clearing the decoded
data. However, calling twice is not even necessary as the entire
buffer cannot be filled up entirely.
Closes GH-16226.
Bisect points to 94ee4f9, however this only reveals the problem.
Cloning an object on a lower branch and trying to call its methods
crashes as well. Cloning the object shouldn't be possible in the first
place because there's an engine constraint that when we have a new
object handler we should also have a clone handler. This constraint is
not fulfilled here.
Closes GH-16245.
