[all-commits] [llvm/llvm-project] d95baa: tsan: fix failures after multi-threaded fork

[Dmitry Vyukov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d95baa98f34f01bea4fdab92c545bd3b24b697ee
      https://github.com/llvm/llvm-project/commit/d95baa98f34f01bea4fdab92c545bd3b24b697ee
  Author: Dmitry Vyukov <dvyukov at google.com>
  Date:   2021-12-21 (Tue, 21 Dec 2021)

  Changed paths:
    M compiler-rt/lib/sanitizer_common/sanitizer_thread_registry.cpp
    M compiler-rt/lib/sanitizer_common/sanitizer_thread_registry.h
    M compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
    M compiler-rt/test/tsan/fork_multithreaded.cpp

  Log Message:
  -----------
  tsan: fix failures after multi-threaded fork

Creating threads after a multi-threaded fork is semi-supported,
we don't give particular guarantees, but we try to not fail
on simple cases and we have die_after_fork=0 flag that enables
not dying on creation of threads after a multi-threaded fork.
This flag is used in the wild:
https://github.com/mongodb/mongo/blob/23c052e3e321dbab90f1863d4d5539d7c1a1cf44/SConstruct#L3599

fork_multithreaded.cpp test started hanging in debug mode
after the recent "tsan: fix deadlock during race reporting" commit,
which added proactive ThreadRegistryLock check in SlotLock.

But the test broke earlier after "tsan: remove quadratic behavior in pthread_join"
commit which made tracking of alive threads based on pthread_t stricter
(CHECK-fail on 2 threads with the same pthread_t, or joining a non-existent thread).
When we start a thread after a multi-threaded fork, the new pthread_t
can actually match one of existing values (for threads that don't exist anymore).
Thread creation started CHECK-failing on this, but the test simply
ignored this CHECK failure in the child thread and "passed".
But after "tsan: fix deadlock during race reporting" the test started hanging dead,
because CHECK failures recursively lock thread registry.

Fix this purging all alive threads from thread registry on fork.

Also the thread registry mutex somehow lost the internal deadlock detector id
and was excluded from deadlock detection. If it would have the id, the CHECK
wouldn't hang because of the nested CHECK failure due to the deadlock.
But then again the test would have silently ignore this error as well
and the bugs wouldn't have been noticed.
Add the deadlock detector id to the thread registry mutex.

Also extend the test to check more cases and detect more bugs.

Reviewed By: melver

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