There is a small chance that the internal allocator is locked
during fork and then the new process is created with locked
internal allocator and any attempts to use it will deadlock.
For example, if detected a suppressed race in the parent during fork
and then another suppressed race after the fork.
This becomes much more likely with the new tsan runtime
as it uses the internal allocator for more things.
Details
Details
- Reviewers
vitalybuka melver - Commits
- rG348389263ca5: tsan: lock internal allocator around fork
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
TSan tests on the buildbot are timing out after this change and https://reviews.llvm.org/D114532. Not sure if there's a deadlock or if it just slowed things down too much.
[31/32] Running ThreadSanitizer tests -- Testing: 439 tests, 80 workers -- command timed out: 1200 seconds without output running [b'python', b'../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py'], attempting to kill process killed by signal 9 program finished with exit code -1 elapsedTime=1967.457687
Comment Actions
I stared at this failure before but couldn't understand if it was a real one or a flake (only one bot failed).
Do we know what's special about this particular bot? Does it use some older OS version or something? I can't find this info anywhere and the output does not contain much useful information (what tests hanged at least)...