https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #5 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Another problem here seems to be
that pthread_cancel() doesn't unpoison
the cancelled thread's stack.
This causes dtors to run on a
randomly poisoned stack, depending
on where the cancellation happened.
That explains the "random" nature of
a crash, and the fact that pthread_cancel()
is in a test-case attached to that ticket,
and in my program as well.
So, the best diagnostic I can come up
with, is that after pthread_cancel() we
have this:
---
#0 __sanitizer::UnsetAlternateSignalStack ()
at
../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:190
#1 0x00007ffff7672f0d in __asan::AsanThread::Destroy (this=0x7ffff358e000)
at ../../../../libsanitizer/asan/asan_thread.cpp:104
#2 0x00007ffff69d2c61 in __GI___nptl_deallocate_tsd ()
at nptl_deallocate_tsd.c:74
#3 __GI___nptl_deallocate_tsd () at nptl_deallocate_tsd.c:23
#4 0x00007ffff69d5948 in start_thread (arg=<optimized out>)
at pthread_create.c:446
#5 0x00007ffff6a5a640 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
---
And its running on a stack previously
poisoned before pthread_cancel().
Then it detects the access to poisoned
area and is trying to do a stack trace.
But that fails too because the redzone
canary is overwritten.
So all we get is a crash.
