Add a C function, opcache_preloading(), that returns true during
preloading. Extensions can use this to detect preloading, not only during
compilation/execution, but also in RINIT()/RSHUTDOWN().
Since opcache currently doesn't install any header, I'm adding a new one:
zend_accelerator_api.h. Header name is based on other files in ext/opcache.
Closes GH-19288
* PHP-8.4:
pdo_odbc: Fix memory leak if WideCharToMultiByte() fails
Fix memory leak on php_odbc_fetch_hash() failure
Do not delete main chunk in zend_gc
* PHP-8.3:
pdo_odbc: Fix memory leak if WideCharToMultiByte() fails
Fix memory leak on php_odbc_fetch_hash() failure
Do not delete main chunk in zend_gc
Debugging memory corruption issues in production can be difficult when it's not possible to use a debug build or ASAN/MSAN/Valgrind (e.g. for performance reasons).
This change makes it possible to enable some basic heap debugging helpers without rebuilding PHP. This is controlled by the environment variable ZEND_MM_DEBUG. The env var takes a comma-separated list of parameters:
- poison_free=byte: Override freed blocks with the specified byte value (represented as a number)
- poison_alloc=byte: Override newly allocated blocks with the specified byte value (represented as a number)
- padding=bytes: Pad allocated blocks with the specified amount of bytes (if non-zero, a value >= 16 is recommended to not break alignments)
- check_freelists_on_shutdown=0|1: Enable checking freelist consistency [1] on shutdown
Example:
ZEND_MM_DEBUG=poison_free=0xbe,poison_alloc=0xeb,padding=16,check_freelists_on_shutdown=1 php ...
This is implemented by installing custom handlers when ZEND_MM_DEBUG is set.
This has zero overhead when ZEND_MM_DEBUG is not set. When ZEND_MM_DEBUG is set, the overhead is about 8.5% on the Symfony Demo benchmark.
Goals:
- Crash earlier after a memory corruption, to extract a useful backtrace
- Be usable in production with reasonable overhead
- Having zero overhead when not enabled
Non-goals:
- Replace debug builds, valgrind, ASAN, MSAN or other sanitizers
[1] https://github.com/php/php-src/pull/14054
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
The FFI call return values follow widening rules.
We must widen to `ffi_arg` in the case we're handling a return value for types shorter than the machine width.
From http://www.chiark.greenend.org.uk/doc/libffi-dev/html/The-Closure-API.html:
> In most cases, ret points to an object of exactly the size of the type specified when cif was constructed.
> However, integral types narrower than the system register size are widened.
> In these cases your program may assume that ret points to an ffi_arg object.
If we don't do this, we get wrong values when reading the return values.
Closes GH-17255.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
This testing code was never meant to be used this way, but fixing this
will at least stop fuzzers from complaining about this, so might still
be worthwhile.
Closes GH-16919.
zlog_buf_prefix() can return a larger length than what actually was
written due to its use of snprintf(). The code in
zlog_stream_prefix_ex() does not take this into account, other callers
do. What ends up happening then is that stream->length is set to the
length as if snprintf() was able to write all bytes, causing
stream->length to become larger than stream->buf.size, causing a
segfault.
In case the buffer was too small we try with a larger buffer up to a
limit of zlog_limit. This makes sure that the stream length will remain
bounded by the buffer size.
This also adds assertions to make the programmer intent clear and catch
this more easily in debug builds.
Closes GH-16680.
* Don't fiddle with NDEBUG in C code
It is way to late to do this in php.h, since assert.h has already been
included. Even pushing that down to zend_portability.h may not have
the desired effect. Instead we define or undefine NDEBUG as CFLAG, so
that it works in all circumstances.
As a last resort we fail at build time, if `NDEBUG` is defined when
`ZEND_DEBUG` is enabled.
We also remove the useless workaround in zend_test to include assert.h
again, since that usually won't have any effect anyway.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
These are equivalent to `zend_hash_clean()` and `zend_hash_destroy()`
respectively, but take care of correctly unregistering the weak references to
the keys.
This addition rounds off the weakmap functionality added in
471102edcd by taking one possible footgun away
from the user.
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.
is_zend_ptr() expected zend_mm_heap.huge_list to be circular, but it's in fact NULL-terminated. It could crash when at least one huge block exists and the ptr did not belong to any block.
This is necessary because `zend_get_attribute_object()` will use the persistent
string with the parameter name as the index for a newly created non-persistent
HashTable, which is not legal.
As parameter names are expected to be short-ish, reasonably common terms and
need to sit around in memory anyways, we might as well make them an interned
string, circumstepping the issue without needing to duplicate the parameter
name into a non-persistent string.
Although the issue was demonstrated using Curl, the issue is purely in
the streams layer of PHP.
Full analysis is written in GH-11078 [1], but here is the brief version:
Here's what actually happens:
1) We're creating a FILE handle from a stream using the casting mechanism.
This will create a cookie-based FILE handle using funopen.
2) We're reading stream data using fread from the userspace stream. This will
temporarily set a buffer into a field _bf.base [2]. This buffer is now equal
to the upload buffer that Curl allocated and note that that buffer is owned
by Curl.
3) The fatal error occurs and we bail out from the fread function, notice how
the reset code is never executed and so the buffer will still point to
Curl's upload buffer instead of FILE's own buffer [3].
4) The resources are destroyed, this includes our opened stream and because the
FILE handle is cached, it gets destroyed as well.
In fact, the stream code calls through fclose on purpose in this case.
5) The fclose code frees the _bs.base buffer [4].
However, this is not the buffer that FILE owns but the one that Curl owns
because it isn't reset properly due to the bailout!
6) The objects are getting destroyed, and so the curl free logic is invoked.
When Curl tries to gracefully clean up, it tries to free the buffer.
But that buffer is actually already freed mistakingly by the C library!
This also explains why we can't reproduce it on Linux: this bizarre buffer
swapping only happens on macOS and BSD, not on Linux.
To solve this, we switch to an unbuffered mode for cookie-based FILEs.
This avoids any stateful problems related to buffers especially when the
bailout mechanism triggers. As streams have their own buffering
mechanism, I don't expect this to impact performance.
[1] https://github.com/php/php-src/issues/11078#issuecomment-2155616843
[2] 5e566be7a7/stdio/FreeBSD/fread.c (L102-L103)
[3] 5e566be7a7/stdio/FreeBSD/fread.c (L117)
[4] 5e566be7a7/stdio/FreeBSD/fclose.c (L66-L67)
Closes GH-14524.
