-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Ensure static TLS region is free'd last #15086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1485cf9
to
95b0a77
Compare
95b0a77
to
3fabe01
Compare
This is needed by a followup PR (#15086) which improves our LSan support. LSan wants to be able to call pthread_key_create during its own startup and doesn't expect allocation to occur during this time: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/compiler-rt/lib/lsan/lsan.cpp#L113 This method of using a static array of keys is also the one used by musl so this seems like a reasonable implementation: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/libc/musl/src/thread/pthread_key_create.c#L8
3fabe01
to
e56bba9
Compare
e56bba9
to
5abe62e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This change depends on #15087.. any chance you could take a look at that too? |
This is needed by a followup PR (#15086) which improves our LSan support. LSan wants to be able to call pthread_key_create during its own startup and doesn't expect allocation to occur during this time: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/compiler-rt/lib/lsan/lsan.cpp#L113 This method of using a static array of keys is also the one used by musl so this seems like a reasonable implementation: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/libc/musl/src/thread/pthread_key_create.c#L8
0f8f650
to
939427a
Compare
5abe62e
to
3498e6e
Compare
…15087) This is needed by a followup PR (#15086) which improves our LSan support. LSan wants to be able to call pthread_key_create during its own startup and doesn't expect allocation to occur during this time: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/compiler-rt/lib/lsan/lsan.cpp#L113 This method of using a static array of keys is also the one used by musl so this seems like a reasonable implementation: https://github.com/emscripten-core/emscripten/blob/6b53dedf3d2ace15bfd780e44f4a8ba34407fc27/system/lib/libc/musl/src/thread/pthread_key_create.c#L8
We were using `__cxa_thread_atexit` to register the funtion for free'ing TLS data. And because were were running the exit handlers `__pthread_exit_run_handlers` before `__pthread_tsd_run_dtors` it meant that any pthread_key descructor functions would not be able to access TLS variables. Instead we really need to delay free'ing of TLS data until all exit handlers and pthread_key descructors have been run. This was causing failure of `lsan.test_stdio_locking` due to the fact that lsan uses TLS during pthread key destruction. Specifically `thread_finalize` (a pthread_key desctructor function) calls `ThreadFinish` which in turn calls `GetCurrentThread` which uses a thread local variable to store the current thread ID. This change should allow #14489 to be dramatically simplified because it will allow the use of TLS variables to implement the atexit queue.
3498e6e
to
dc448d4
Compare
@@ -562,15 +562,14 @@ void InitializeInterceptors() { | |||
LSAN_MAYBE_INTERCEPT_PTHREAD_ATFORK; | |||
|
|||
LSAN_MAYBE_INTERCEPT_STRERROR; | |||
#endif // !SANITIZER_FUCHSIA && !SANITIZER_EMSCRIPTEN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the movement of the fuscia ifdef here a divergence from upstream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(otherwise lgtm)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes, I hadn't realized I had effect fuchsia here. Will follow up.
…dling As well use being less code to maintain and more shared code this also enables thread exit handling which means ASan now tracks thread exit where it didn't before. With the old/existing code noone was ever calling the ASan thread destructor (passed as arg0 to AsanTSDInit). I imagine this approach might not have been possible in the past since there were some issues with using pthread_keys with destructors (e.g. #15086). Testing by running entire `asan` test suite.
In #15086 the intent was to enable `g_thread_finalize_key` under emscripten but I unwittingly modified the ifdef region used by fuchsia is well.
In #15086 the intent was to enable `g_thread_finalize_key` under emscripten but I unwittingly modified the ifdef region used by fuchsia is well.
…dling (#15095) As well use being less code to maintain and more shared code this also enables thread exit handling which means ASan now tracks thread exit where it didn't before. With the old/existing code noone was ever calling the ASan thread destructor (passed as arg0 to AsanTSDInit). I imagine this approach might not have been possible in the past since there were some issues with using pthread_keys with destructors (e.g. #15086). Testing by running entire `asan` test suite.
We were using
__cxa_thread_atexit
to register the funtion for free'ingTLS data. And because were were running the exit handlers
__pthread_exit_run_handlers
before__pthread_tsd_run_dtors
it meantthat any pthread_key descructor functions would not be able to access
TLS variables.
Instead we really need to delay free'ing of TLS data until all exit
handlers and pthread_key descructors have been run.
This was causing failure of
lsan.test_stdio_locking
due to the factthat lsan uses TLS during pthread key destruction. Specifically
thread_finalize
(a pthread_key desctructor function) callsThreadFinish
which in turn callsGetCurrentThread
which uses athread local variable to store the current thread ID.
This change should allow #14489 to be dramatically simplified because
it will allow the use of TLS variables to implement the atexit queue.