https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88400
--- Comment #5 from hhj <He.Hongjun at zte dot com.cn> --- (In reply to Richard Biener from comment #2) > Please provide a testcase to reproduce the issue. Also note that GCC 6 is > no longer supported. This sounds like an issue in the libsanitizer > interceptor > to me, the pthread_create interceptor does > > // Wait until the AsanThread object is initialized and the ThreadRegistry > // entry is in "started" state. One reason for this is that after this > // interceptor exits, the child thread's stack may be the only thing > holding > // the |arg| pointer. This may cause LSan to report a leak if leak > checking > // happens at a point when the interceptor has already exited, but the > stack > // range for the child thread is not yet known. > while (atomic_load(¶m.is_registered, memory_order_acquire) == 0) > internal_sched_yield(); > > but sched_yield should allow other threads to do progress. That might not > work if the current thread is realtime of course. But isn't that a > user error (or a kernel bug when explicitely yield()ing)? It isn't user error or a kernel bug. the user's program is normal, and kernel is no bug when explicitely yield()ing. It's address-sanitizer's bug. Adding address-sanitizer, it is deadlock because of parent and child threads wait of resources from each other. We deal with the bug by raising the priority of parent or child threads. Then the pthread_create is ok.