From 0e367b9938841ef0a7789d6d7ce70de2145e73da Mon Sep 17 00:00:00 2001 From: Denis Khalikov Date: Wed, 26 Apr 2017 18:27:29 +0300 Subject: [PATCH] commit 6fdba17a20fd7c5f31f39556dc511abe3a537204 Author: Maxim Ostapenko Date: Fri Oct 28 06:49:53 2016 +0000 [asan/lsan] Avoid possible deadlock in dynamic ASan runtime thread initialization. There is possible deadlock in dynamic ASan runtime when we dlopen() shared lib which creates a thread at the global initialization stage. The scenario: 1) dlopen grabs a GI_pthread_mutex_lock in main thread. 2) main thread calls pthread_create, ASan intercepts it, calls real pthread_create and waits for the second thread to be "fully initialized". 3) Newly created thread tries to access a thread local disable_counter in LSan (to complete its "full initialization") and hangs in tls_get_addr_tail, because it also tries to acquire GI_pthread_mutex_lock. The issue is reproducible on relative recent Glibc versions e.g. 2.23. Differential Revision: https://reviews.llvm.org/D26028 Change-Id: I0ed82cb81dd9d37d0be96ece03b667090b72164a --- libsanitizer/lsan/lsan_common.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/libsanitizer/lsan/lsan_common.cc b/libsanitizer/lsan/lsan_common.cc index 866e23f..5c92e32 100644 --- a/libsanitizer/lsan/lsan_common.cc +++ b/libsanitizer/lsan/lsan_common.cc @@ -33,6 +33,7 @@ namespace __lsan { // also to protect the global list of root regions. BlockingMutex global_mutex(LINKER_INITIALIZED); +__attribute__((tls_model("initial-exec"))) THREADLOCAL int disable_counter; bool DisabledInThisThread() { return disable_counter > 0; } -- 2.7.4