[asan/lsan] Avoid possible deadlock in dynamic ASan runtime thread initialization.

[m.ostapenko]

Summary

As was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982, there is possible deadlock in dynamic ASan runtime when we dlopen() shared lib which creates a thread at the global initialization stage. Here is 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 doesn't reproduce on older Glibc (e.g. 2.19 on my Ubuntu box) because tls_get_addr_tail doesn't try to acquire GI_pthread_mutex_lock there, but reproducible on more recent ones, e.g. Glibc 2.23.

The deadlock doesn't occur with ASan static linkage because in this case disable_counter resides in static tls, thus tls_get_addr_tail isn't called.

The simple fix would be just using attribute((tls_model("initial-exec"))) for disable_counter in LSan. This should be fine since nobody would dlopen {A, L}San runtime in any case.

[kcc]

LGTM
Thanks for investigation and the fix!

compiler-rt/trunk/lib/lsan/lsan_common.cc

 
 #if CAN_SANITIZE_LEAKS
 namespace __lsan {
 
 // This mutex is used to prevent races between DoLeakCheck and IgnoreObject, and
 // 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; }
 void DisableInThisThread() { disable_counter++; }
 void EnableInThisThread() {
   if (!disable_counter && common_flags()->detect_leaks) {
     Report("Unmatched call to __lsan_enable().\n");
     Die();
   }

compiler-rt/trunk/test/asan/TestCases/Linux/pthread_create_from_constructor.cc

+// Test that ASan doesn't deadlock in __interceptor_pthread_create called
+// from dlopened shared library constructor. The deadlock happens only in shared
+// ASan runtime with recent Glibc (2.23 fits) when __interceptor_pthread_create
+// grabs global Glibc's GL(dl_load_lock) and waits for tls_get_addr_tail that
+// also tries to acquire it.
+//
+// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared %s -o %t-so.so
+// RUN: %clangxx_asan %s -o %t
+// RUN: %run %t 2>&1
+
+// dlopen() can not be intercepted on Android
+// UNSUPPORTED: android
+
+#ifdef BUILD_SO
+
+#include <stdio.h>
+#include <pthread.h>
+#include <unistd.h>
+
+void *threadFn(void *) {
+  fprintf(stderr, "thread started\n");
+  while (true) {
+    usleep(100000);
+  }
+  return 0;
+}
+
+void __attribute__((constructor)) startPolling() {
+  fprintf(stderr, "initializing library\n");
+  pthread_t t;
+  pthread_create(&t, 0, &threadFn, 0);
+  fprintf(stderr, "done\n");
+}
+
+#else
+
+#include <dlfcn.h>
+#include <stdlib.h>
+#include <string>
+
+int main(int argc, char **argv) {
+  std::string path = std::string(argv[0]) + "-so.so";
+  void *handle = dlopen(path.c_str(), RTLD_LAZY);
+  if (!handle)
+    abort();
+  return 0;
+}
+#endif