[asan/lsan] Avoid possible deadlock in dynamic ASan runtime thread initialization.
authorMaxim Ostapenko <m.ostapenko@partner.samsung.com>
Fri, 28 Oct 2016 06:49:53 +0000 (06:49 +0000)
committerMaxim Ostapenko <m.ostapenko@partner.samsung.com>
Fri, 28 Oct 2016 06:49:53 +0000 (06:49 +0000)
commit984f42eed5252a487ac274e16ffcb7c48d9032f5
tree13b5310a0209391f012dc2334a967fec680bff38
parent64428acf41943b929e9ebc8e83cfaad2f76ab33a
[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

llvm-svn: 285385
compiler-rt/lib/lsan/lsan_common.cc
compiler-rt/test/asan/TestCases/Linux/pthread_create_from_constructor.cc [new file with mode: 0644]