[TSan] Fix a rare deadlock on multithreaded fork.
commite2bc261e483ca8fe4669626ba06f0d8404a55cf1
authorAlexey Samsonov <samsonov@google.com>
Thu, 3 Apr 2014 12:51:26 +0000 (3 12:51 +0000)
committerAlexey Samsonov <samsonov@google.com>
Thu, 3 Apr 2014 12:51:26 +0000 (3 12:51 +0000)
treecffbd5279f640b798f5b662df32afb75dc5b6131
parent80dd65a8fcfa9d7a5aeeeb165ec48c6f6787ef16
[TSan] Fix a rare deadlock on multithreaded fork.

If a multi-threaded program calls fork(), TSan ignores all memory accesses
in the child to prevent deadlocks in TSan runtime. This is OK, as child is
probably going to call exec() as soon as possible. However, a rare deadlocks
could be caused by ThreadIgnoreBegin() function itself.

ThreadIgnoreBegin() remembers the current stack trace and puts it into the
StackDepot to report a warning later if a thread exited with ignores enabled.
Using StackDepotPut in a child process is dangerous: it locks a mutex on
a slow path, which could be already locked in a parent process.

The fix is simple: just don't put current stack traces to StackDepot in
ThreadIgnoreBegin() and ThreadIgnoreSyncBegin() functions if we're
running after a multithreaded fork. We will not report any
"thread exited with ignores enabled" errors in this case anyway.

Submitting this without a testcase, as I believe the standalone reproducer
is pretty hard to construct.

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@205534 91177308-0d34-0410-b5e6-96231b3b80d8
lib/tsan/rtl/tsan_rtl.cc