mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-16 15:26:47 +00:00
7f10ed637e
Sometime tsan runtimes calls, like `__tsan_mutex_create ()`, need to store a stack in the StackDepot, and the Depot may need to start and maintenance thread. Example: ``` __sanitizer::FutexWait () __sanitizer::Semaphore::Wait () __sanitizer::Mutex::Lock () __tsan::SlotLock () __tsan::SlotLocker::SlotLocker () __tsan::Acquire () __tsan::CallUserSignalHandler () __tsan::ProcessPendingSignalsImpl () __tsan::ProcessPendingSignals () __tsan::ScopedInterceptor::~ScopedInterceptor () ___interceptor_mmap () pthread_create () __sanitizer::internal_start_thread () __sanitizer::(anonymous namespace)::CompressThread::NewWorkNotify () __sanitizer::StackDepotNode::store () __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1, 20>::Put () __tsan::CurrentStackId () __tsan::MutexCreate () __tsan_mutex_create () ``` pthread_create() implementation may hit other interceptors recursively, which may invoke ProcessPendingSignals, which deadlocks. Alternative solution could be block interceptors closer to TSAN runtime API function, like `__tsan_mutex_create`, or just before `StackDepotPut``, but it's not needed for most calls, only when new thread is created using `real_pthread_create`. I don't see a reasonable way to create a regression test.