The TSRM keeps a hashtable mapping the thread IDs to the thread resource pointers.
It's possible that the thread disappears without us knowing, and then another thread
gets spawned some time later with the same ID as the disappeared thread.
Note that since it's a new thread the TSRM key pointer and cached pointer will be NULL.
The Apache request handler `php_handler()` will try to fetch some fields from the SAPI globals.
It uses a lazy thread resource allocation by calling `ts_resource(0);`.
This allocates a thread resource and sets up the TSRM pointers if they haven't been set up yet.
At least, that's what's supposed to happen. But since we are in a situation where the thread ID
still has the resources of the *old* thread associated in the hashtable,
the loop in `ts_resource_ex` will find that thread resource and assume the thread has been setup
already. But this is not the case since this thread is actually a new thread, just reusing the ID
of the old one, without any relation whatsoever to the old thread.
Because of this assumption, the TSRM pointers will not be setup, leading to a
NULL pointer dereference when trying to access the SAPI globals.
We can easily detect this scenario: if we're in the fallback path, and the pointer is NULL,
and we're looking for our own thread resource, we know we're actually reusing a thread ID.
In that case, we'll free up the old thread resources gracefully (gracefully because
there might still be resources open like database connection which need to be
shut down cleanly). After freeing the resources, we'll create the new resources for
this thread as if the stale resources never existed in the first place.
From that point forward, it is as if that situation never occurred.
The fact that this situation happens isn't that bad because a child process containing
threads will eventually be respawned anyway by the SAPI, so the stale thread resources
won't remain forever.
Note that we can't simply assign our own TSRM pointers to the existing
thread resource for our ID, since it was actually from a different thread
(just with the same ID!). Furthermore, the dynamically loaded extensions
have their own pointer, which is only set when their constructor is
called, so we'd have to call their constructor anyway...
I also tried to call the dtor and then the ctor again for those resources
on the pre-existing thread resource to reuse storage, but that didn't work properly
because other code doesn't expect something like that to happen, which breaks assumptions,
and this in turn caused Valgrind to (rightfully) complain about memory bugs.
Note 2: I also had to fix a bug in the core globals destruction because it
always assumed that the thread destroying them was the owning thread,
which on TSRM shutdown isn't always the case. A similar bug was fixed
recently with the JIT globals.
Closes GH-10863.
Don't misinterpret DJI info maker note as DJI maker note.
The DJI and DJI info maker note both share the "DJI" make string.
This caused the current code to try to interpret the DJI info maker note
as a DJI maker note. However, the DJI info maker note requires custom
parsing. Therefore, the misinterpretation actually caused the current
code to believe that there was an unrecoverable error in the IFD for the
maker note by returning false in the maker note parser. This in turn
caused the inability to parse other EXIF metadata.
This patch adds the identification of the DJI info maker note so that it
cannot be misinterpreted. Since we don't implement custom parsing, it
achieves this by setting the tag list to a special marker value (in this
case the NULL pointer). When this marker value is detected, the function
will just skip parsing the maker note and return true. Therefore, the
other code will believe that the IFD is not corrupt.
This approach is similar to handing an unrecognised maker note type
(see the loop on top of exif_process_IFD_in_MAKERNOTE() which also
returns true and treats it as a string). The end result of this patch
is that the DJI info maker note is considered as unknown to the caller of
exif_process_IFD_in_MAKERNOTE(), and therefore that the other EXIF
metadata can be parsed successfully.
Also fix debug output typos in exif.
Closes GH-10470.
Discovered this pre-existing problem while testing GH-10682.
Note: this problem existed *before* that PR.
* Not all paths throw a hierarchy request error
* xmlFreeNode must be used instead of xmlFree for the fragment to also
free its children.
* Free up nodes that couldn't be added when xmlAddChild fails.
I unified the error handling code that's exactly the same with a goto to
prevent at least some of such problems in the future.
Closes GH-10981.
This is a variant of GH-10200, but in a different place.
Basically, simplexml may create a properties table that's packed instead
of associative. But the macro that was used to loop over the properties
table assumed that it was always associative. Replace it by the macro
that figures it out automatically which one of the two it is.
For test: Co-authored-by: jnvsor
Closes GH-10984.
* PHP-8.1:
Fix GH-10990: mail() throws TypeError after iterating over $additional_headers array by reference
Fix GH-8841: php-cli core dump calling a badly formed function
It's actually not php-cli specific, nor SAPI specific.
We should delay the registration of the function into the function table
until after the compilation was successful, otherwise the function is
mistakingly registered and a NULL dereference will happen when trying to
call it.
I based my test of Nikita's test, so credits to him for the test:
https://github.com/php/php-src/pull/8933#issuecomment-1259881008
Closes GH-10989.
The ZVAL_ARR macro always set the zval type_info to IS_ARRAY_EX, even if the
hash table is immutable. Since in preg_replace_callback_array() we can return
the passed array directly, and that passed array can be immutable, we need to
reset the type_flags to keep the VM from performing ref-counting on the array.
Fixes GH-10968
Closes GH-10970
This change restores the old behaviour for the server socket streams
that don't support IO. This is now stored in the stream flags so it can
be later used to do some other decisions and possibly introduce some
better error reporting.
Closes GH-10877
This was first pointed out in GH-10959.
The from_zval_... functions don't always write to the pointer, in particular
it is necessary to check for an error before using the value. Otherwise
we can access an uninitialized value and that's UB (and dangerous).
Note: this does *NOT* get rid of the compiler warning. Even though there
is error checking now, the compiler isn't smart enough to figure out
that the values can not be used uninitialized.
Closes GH-10966.
atoi()'s return value is actually undefined when an underflow or
overflow occurs. For example on 32-bit on my system the overflow test
which inputs "h2147483648" results in repetitions==2147483647 and on
64-bit this gives repetitions==-2147483648. The reason the test works on
32-bit is because there's a second undefined behaviour problem:
in case 'h' when repetitions==2147483647, we add 1 and divide by 2.
This is signed-wrap undefined behaviour and accidentally triggers the
overflow check like we wanted to.
Avoid all this trouble and use strtol with explicit error checking.
This also fixes a semantic bug where repetitions==INT_MAX would result
in the overflow check to trigger, even though there is no overflow.
Closes GH-10943.
The recent clang-16 throws errors for implicitly defined functions by
default. In many ./configure tests, an undefined function (which is
"implicitly defined" when you try to call it) is undefined because it
really does not exist. But in one case, utf8_to_mutf7() is undefined
because we forgot to include the header that defines it.
This commit updates the test for utf8_to_mutf7:
* We now include the header (c-client.h) that defines it.
* A "checking... yes/no" message was added to the test.
* The test was switched from PHP_IMAP_TEST_BUILD to AC_COMPILE_IFELSE.
This was the easiest way to avoid a return-type mismatch that runs
afoul of -Werror=implicit-int.
* CPPFLAGS is temporarily amended with the -I flag needed to find
c-client.h.
Fixes GH-10947.
Closes GH-10948
Signed-off-by: George Peter Banyard <girgias@php.net>
It turns out that the version of Firebird influences the test in terms
of supported data types. On Windows on 8.2 we seem to be using a
different version than on 8.1. Fix it by amending the test.
The core issue is still tested in the test, it's just that not all
datatypes are tested anymore (which isn't strictly necessary anyway).
Dmitry Stogov