mirror of
https://github.com/php/php-src.git
synced 2024-12-18 14:30:35 +08:00
51faf04dbd
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. |
||
|---|---|---|
| .. | ||
| config.w32 | ||
| LICENSE | ||
| threads.m4 | ||
| tsrm_win32.c | ||
| tsrm_win32.h | ||
| TSRM.c | ||
| TSRM.h | ||
| tsrm.m4 | ||