tree c40d7fef988a8e41ab0235ba0853bc5bb8fd541d
parent 88cf57774abbf7dc1750a755b85b34a157e5fd79
author Dmitry Vyukov <dvyukov@google.com> 1664539107 +0200
committer Copybara-Service <copybara-worker@google.com> 1664540755 -0700

tsan: fix deadlock/crash in signal handling

We set in_blocking_func around some blocking C functions so that we don't
delay signal infinitely (if in_blocking_func is set we deliver signals
synchronously).

However, pthread_join is blocking but also call munmap/free to free thread
resources. If we are inside the munmap/free interceptors called from
pthread_join and deliver a signal synchronously, it can lead to deadlocks
and crashes since we re-enter runtime and try to lock the same mutexes
or use the same per-thread data structures.

If we re-enter runtime via an interceptor when in_blocking_func is set,
temporary reset in_blocking_func around the interceptor and restore it back
when we return from the recursive interceptor.

Also move in_blocking_func from ThreadSignalContext to ThreadContext
so that we can CHECK that it's not set in SlotLocker ctor.

Fixes https://github.com/google/sanitizers/issues/1540

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D127845

GitOrigin-RevId: 3056ccdbae7c36e4eaa2ac89bc82d9c94bddd77a