OSX: use after free in thread_local when a TLS location isn't initialized until destruction of another TLS location
#57534
Comments
mtak-
changed the title
thread_local when a TLS location isn't get initialized until destruction of another TLS locationthread_local when a TLS location isn't initialized until destruction of another TLS location
|
Might be related to / caused by #28129 |
|
Looking at the source code for This is worse than just not running tls destructors for the main thread. It is unsound AFAICT. |
Centril
added
O-macos
|
Thanks for debugging this @mtak-! I wonder if we can fix this on our end? We might be able to prevent new TLS slots from being initialized after a thread has exited perhaps? |
|
I don't know how to reliably detect that a thread is exiting using the APIs that OSX provides (there could be a way). The logic in Apple's threadLocalVariables.c looks similar to what already exists in register_dtor_fallback, except that FWIW C++ has similar problems with "static local" thread locals when compiled by appleclang. #include <iostream>
struct A {
int x;
~A();
};
thread_local A thread_a{3557};
A::~A() {
static thread_local std::string thread_string{"hello there long enough string"};
// next line triggers a call to _tlv_atexit during tlv_finalize, and makes ASAN unhappy
std::cout << thread_string << std::endl;
}
int main() {
std::cout << thread_a.x << std::endl;
return 0;
} |
|
Makes sense yeah, perhaps as a fallback solution we could just fix this issue for Rust-spawned threads? For those we know exactly when they're exiting (or at least when user-written Rust code has ceased executing) and that may be enough too! Skipping |
…ichton OSX: fix rust-lang#57534 registering thread dtors while running thread dtors r? @alexcrichton - "fast" `thread_local` destructors get run even on the main thread - "fast" `thread_local` dtors, can initialize other `thread_local`'s One corner case where this fix doesn't work, is when a C++ `thread_local` triggers the initialization of a rust `thread_local`. I did not add any std::thread specific flag to indicate that the thread is currently exiting, which would be checked before registering a new dtor (I didn't really know where to stick that). I think this does the trick tho! Let me know if anything needs tweaking/fixing/etc. resolves this for macos: rust-lang#28129 fixes: rust-lang#57534
…ichton OSX: fix rust-lang#57534 registering thread dtors while running thread dtors r? @alexcrichton - "fast" `thread_local` destructors get run even on the main thread - "fast" `thread_local` dtors, can initialize other `thread_local`'s One corner case where this fix doesn't work, is when a C++ `thread_local` triggers the initialization of a rust `thread_local`. I did not add any std::thread specific flag to indicate that the thread is currently exiting, which would be checked before registering a new dtor (I didn't really know where to stick that). I think this does the trick tho! Let me know if anything needs tweaking/fixing/etc. resolves this for macos: rust-lang#28129 fixes: rust-lang#57534
pnkfelix
added
T-libs-api
|
visiting for T-compiler triage. Retagged as T-libs. |
OSX: fix #57534 registering thread dtors while running thread dtors r? @alexcrichton - "fast" `thread_local` destructors get run even on the main thread - "fast" `thread_local` dtors, can initialize other `thread_local`'s One corner case where this fix doesn't work, is when a C++ `thread_local` triggers the initialization of a rust `thread_local`. I did not add any std::thread specific flag to indicate that the thread is currently exiting, which would be checked before registering a new dtor (I didn't really know where to stick that). I think this does the trick tho! Let me know if anything needs tweaking/fixing/etc. resolves this for macos: #28129 fixes: #57534
|
Filed an apple bug report. openradar link |
Moved from Amanieu/parking_lot#114 because the issue is not specific to
parking_lot.Repro:
RUSTFLAGS="-Z sanitizer=address" cargo runIf thread is changed to access
THREAD_STRINGbefore exiting, then the ASAN error goes away.Address Sanitizer Log
The text was updated successfully, but these errors were encountered: