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(&param.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.

Reply via email to