History log of /php-src/TSRM/TSRM.c (Results 1 – 25 of 140)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 89c4e4c4 04-Jun-2024 Niels Dossche <7771979+nielsdos@users.noreply.github.com>

Fix GH-11188: Error when building TSRM in ARM64 (for IR JIT) (#14459)

This is GH-11236 for IR JIT.


# 2d6bd164 28-Mar-2024 Paul Ripke

Fixed GH-13581: threaded mod_php fails on NetBSD with No space available for Thread Local Storage.

Close GH-13832


# 5941cdaa 13-Feb-2024 Niels Dossche <7771979+nielsdos@users.noreply.github.com>

Fix ZTS crashes with persistent resources in modules (#13381)

On shutdown in ZTS the following happens:
- https://github.com/php/php-src/blob/master/Zend/zend.c#L1124-L1125
gets ex

Fix ZTS crashes with persistent resources in modules (#13381)

On shutdown in ZTS the following happens:
- https://github.com/php/php-src/blob/master/Zend/zend.c#L1124-L1125
gets executed. This destroys global persistent resources and destroys
the modules. Furthermore, the modules are unloaded too.
- Further down, `ts_free_id(executor_globals_id)` gets executed, which
calls `executor_globals_dtor`. This function destroys persistent
resources for each thread.

Notice that in the last step, the modules that the persistent resource
belong to may already have been destroyed. This means that accessing
globals will cause a crash (I previously fixed this with ifdef magic),
or when the module is dynamically loaded we'll try jumping to a
destructor that is no longer loaded in memory. These scenarios cause
crashes.

It's not possible to move the `ts_free_id` call upwards, because that
may break assumptions of callers, and furthermore this would deallocate
the executor globals structure, which means that any access to those
will cause a segfault.

This patch adds a new API to the TSRM that allows running a callback on
a certain resource type. We use this API to destroy the persistent
resources in all threads prior to the module destruction, and keep the
rest of the resource dtor intact.

I verified this fix on Apache with postgres, both dynamically and
statically.

Fixes GH-12974.

show more ...


# 51faf04d 15-Mar-2023 Niels Dossche <7771979+nielsdos@users.noreply.github.com>

Fix GH-10737: PHP 8.1.16 segfaults on line 597 of sapi/apache2handler/sapi_apache2.c

The TSRM keeps a hashtable mapping the thread IDs to the thread resource pointers.
It's possible that

Fix GH-10737: PHP 8.1.16 segfaults on line 597 of sapi/apache2handler/sapi_apache2.c

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.

show more ...


# 7c3b92fc 17-Feb-2023 Ilija Tovilo

Fix strict prototypes warnings


# 9da75d0c 22-Oct-2022 Kévin Dunglas

fix: no-op when signal handlers are called on threads not managed by PHP (#9766)


Revision tags: php-8.2.0RC1, php-8.1.10, php-8.0.23, php-8.0.23RC1, php-8.1.10RC1, php-8.2.0beta3, php-8.2.0beta2, php-8.1.9, php-8.0.22, php-8.1.9RC1, php-8.2.0beta1, php-8.0.22RC1, php-8.0.21, php-8.1.8, php-8.2.0alpha3, php-8.1.8RC1, php-8.2.0alpha2, php-8.0.21RC1, php-8.0.20, php-8.1.7, php-8.2.0alpha1, php-7.4.30, php-8.1.7RC1, php-8.0.20RC1
# 5ba6ecd5 24-May-2022 George Peter Banyard

Minor refactoring of main/main.c and TSRM (#8608)

Revision tags: php-8.1.6, php-8.0.19, php-8.1.6RC1
# 4c0639df 26-Apr-2022 Christoph M. Becker

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
Haiku fix ZTS build disabling `tsrm_ls_cache` usage.


Revision tags: php-8.0.19RC1, php-8.0.18, php-8.1.5, php-7.4.29
# 4bb0dd49 11-Apr-2022 David Carlier

Haiku fix ZTS build disabling `tsrm_ls_cache` usage.

# 097c9271 11-Apr-2022 Christoph M. Becker

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
Move locks in TSRM.c to prevent races


# 1a75269c 03-Apr-2022 ryancaicse <73822648+ryancaicse@users.noreply.github.com>

Move locks in TSRM.c to prevent races

Closes GH-8298.

Revision tags: php-8.1.5RC1, php-8.0.18RC1, php-8.1.4, php-8.0.17
# 0b1bca6b 11-Mar-2022 Christoph M. Becker

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
Fix GH-8160: ZTS support on Alpine is broken


# 2b2aeb98 07-Mar-2022 Michael Voříšek

Fix GH-8160: ZTS support on Alpine is broken

We need to export `__MUSL__` so that phpize builds can see the proper
macro, and also need to fix "_tsrm_ls_cache" usage for musl.

C

Fix GH-8160: ZTS support on Alpine is broken

We need to export `__MUSL__` so that phpize builds can see the proper
macro, and also need to fix "_tsrm_ls_cache" usage for musl.

Closes GH-8180.

show more ...

Revision tags: php-8.1.4RC1, php-8.0.17RC1, php-8.1.3, php-8.0.16, php-7.4.28, php-8.1.3RC1, php-8.0.16RC1, php-8.1.2, php-8.0.15
# f9bf5f48 11-Jan-2022 Joe Watkins

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
Fix TSRM ignoring done


Revision tags: php-8.1.2RC1, php-8.0.15RC1, php-8.0.14, php-8.1.1, php-7.4.27, php-8.1.1RC1, php-8.0.14RC1, php-7.4.27RC1, php-8.1.0, php-8.0.13, php-7.4.26, php-7.3.33, php-8.1.0RC6
# d7db5f6e 05-Nov-2021 Joe Watkins

Fix TSRM ignoring done

# 00405717 17-Nov-2021 Nikita Popov

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
OpenBSD ZTS build fix


# fb3e646f 16-Nov-2021 David Carlier

OpenBSD ZTS build fix

Closes GH-7661.

Revision tags: php-7.4.26RC1, php-8.0.13RC1, php-8.1.0RC5, php-7.3.32, php-7.4.25, php-8.0.12, php-8.1.0RC4, php-8.0.12RC1, php-7.4.25RC1, php-8.1.0RC3, php-8.0.11, php-7.4.24, php-7.3.31, php-8.1.0RC2, php-7.4.24RC1, php-8.0.11RC1, php-8.1.0RC1, php-7.4.23, php-8.0.10, php-7.3.30, php-8.1.0beta3, php-8.0.10RC1, php-7.4.23RC1, php-8.1.0beta2, php-8.0.9, php-7.4.22, php-8.1.0beta1, php-7.4.22RC1, php-8.0.9RC1, php-8.1.0alpha3, php-7.4.21, php-7.3.29
# aff36587 29-Jun-2021 Patrick Allaert

Fixed some spaces used instead of tabs

Revision tags: php-8.0.8, php-8.1.0alpha2, php-7.4.21RC1, php-8.0.8RC1, php-8.1.0alpha1, php-8.0.7, php-7.4.20
# 7c2a3a94 31-May-2021 Hao Sun

JIT/AArch64: [macos][ZTS] Support fast path for tlv_get_addr (#7042)

* JIT/AArch64: [macos][ZTS] Support fast path for tlv_get_addr

Access to TLV(thread local variable) in macOS is

JIT/AArch64: [macos][ZTS] Support fast path for tlv_get_addr (#7042)

* JIT/AArch64: [macos][ZTS] Support fast path for tlv_get_addr

Access to TLV(thread local variable) in macOS is in "dynamic" form and
function tlv_get_addr() is invoked to resolve the address. See the
example in [1].

Note there is one struct TLVDescriptor [2] for each TLV. The first
member holds the address of function tlv_get_addr(), and the other two
members, "key" and "offset", would be used inside tlv_get_addr().

The disassembly code for function tlv_get_addr() is shown in [3]. With
the value from system register, i.e. tpidrro_el0, together with "key"
and "offset", the TLV address can be obtained.

Note that the value from tpidrro_el0 varies for different threads, and
unique address for TLV is resolved.

It's worth noting that slow path would be executed, i.e. function
tlv_allocate_and_initialize_for_key(), for the first time of TLV access.

In this patch:
1. "_tsrm_ls_cache" is guaranteed to be accessed before any VM/JIT code
during the request startup, e.g. in init_executor(), therefore, slow
path can be avoided.

2. As TLVDecriptor is immutable and zend_jit_setup() executes once, we
get this structure in tsrm_get_ls_cache_tcb_offset(). Note the 'ldr'
instruction would be patched to 'add' by the linker.

3. Only fast path for tlv_get_addr() is implemented in macro
LOAD_TSRM_CACHE.

With this patch, all ~4k test cases can pass for ZTS+CALL in macOS on
Apple silicon.

[1] https://gist.github.com/shqking/4aab67e0105f7c1f2c549d57d5799f94
[2]
https://opensource.apple.com/source/dyld/dyld-195.6/src/threadLocalVariables.c.auto.html
[3] https://gist.github.com/shqking/329d7712c26bad49786ab0a544a4af43

Change-Id: I613e9c37e3ff2ecc3fab0f53f1e48a0246e12ee3

show more ...

Revision tags: php-8.0.7RC1, php-7.4.20RC1, php-8.0.6, php-7.4.19, php-7.4.18, php-7.3.28, php-8.0.5
# 735e4ccf 26-Apr-2021 Dmitry Stogov

Support for ZTS

Revision tags: php-8.0.5RC1, php-7.4.18RC1, php-8.0.4RC1, php-7.4.17RC1
# 3b377b51 10-Mar-2021 Dmitry Stogov

Fixed bug #80814 (threaded mod_php won't load on FreeBSD: No space available for static Thread Local Storage)

Revision tags: php-8.0.3, php-7.4.16, php-8.0.3RC1, php-7.4.16RC1, php-8.0.2, php-7.4.15, php-7.3.27, php-8.0.2RC1, php-7.4.15RC2, php-7.4.15RC1, php-8.0.1, php-7.4.14, php-7.3.26, php-7.4.14RC1, php-8.0.1RC1, php-7.3.26RC1, php-8.0.0, php-7.3.25, php-7.4.13, php-8.0.0RC5, php-7.4.13RC1, php-8.0.0RC4, php-7.3.25RC1, php-7.4.12, php-8.0.0RC3, php-7.3.24, php-8.0.0RC2, php-7.4.12RC1, php-7.3.24RC1, php-7.2.34, php-8.0.0rc1, php-7.4.11, php-7.3.23, php-8.0.0beta4, php-7.4.11RC1, php-7.3.23RC1, php-8.0.0beta3, php-7.4.10, php-7.3.22, php-8.0.0beta2, php-7.3.22RC1, php-7.4.10RC1, php-8.0.0beta1, php-7.4.9, php-7.2.33, php-7.3.21, php-8.0.0alpha3, php-7.4.9RC1, php-7.3.21RC1, php-7.4.8, php-7.2.32, php-8.0.0alpha2, php-7.3.20, php-8.0.0alpha1, php-7.4.8RC1, php-7.3.20RC1, php-7.4.7, php-7.3.19
# 88355dd3 07-Jun-2020 twosee

Constify char * arguments of APIs

Closes GH-5676.

# 1b85e749 06-Jun-2020 twosee

Fix warning of strict-prototypes

Closes GH-5673.

Revision tags: php-7.4.7RC1, php-7.3.19RC1
# 1f72dd89 20-May-2020 George Peter Banyard

Fix [-Wundef] warning in TSRM

# 3302ffb0 17-May-2020 George Peter Banyard

Fix bogus check in TSRM and adjust TSRM_ASSERT macro

Closes GH-5562

123456