Bug ID: 88400
Summary: address-sanitizer on the cpu with only one core, may
Assignee: unassigned at gcc dot gnu.org
Reporter: He.Hongjun at zte dot com.cn
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
using address-sanitizer on the cpu with only one core or binding one core,
pthread_create will be deadlock when we create real-time thread.
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
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
// 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
// range for the child thread is not yet known.
while (atomic_load(¶m.is_registered, memory_order_acquire) == 0)
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)?
--- Comment #4 from hhj <He.Hongjun at zte dot com.cn> ---
(In reply to Andrew Pinski from comment #3)
> Also this seems like it is an upstream issue too.
This is how we handle it.
When the parent's sched_priority isn't sam as the children's
1 If the parent's sched_priority is greater than the children's, raising the
children's sched_priority. After register children, restore the children's
2 If children's sched_priority is greater than the parent's, raising the
parent's sched_priority. After register children, restore the parent's