https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
--- Comment #11 from Maxim Ostapenko <m.ostapenko at samsung dot com> --- Created attachment 39882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39882&action=edit Untested fix Untested fix (works for me with attached testcase). To sum up: 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 (yes, 2.19 and 2.23 have many differences in TLS implementation). 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.
