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>
php_pdo_firebird.dll depends on fbclient.dll, which is shipped with the
server. However, a 64bit Firebird server ships a 64bit fbclient.dll,
which is not compatible with a 32bit php_pdo_firebird.dll.
Closes GH-16223.
php-sdk-2.2.0 still fetches dependencies from the no longer up to date
<https://windows.php.net/downloads/php-sdk/deps/>, and as such won't be
tested with any security updates we provide for Windows. Given that
PHP 8.1 is going to receive security updates for further 15 months, we
should should not ignore these dependency updates.
Closes GH-16097.
