Previously in ASan's pthread_create interceptor we would block in the
pthread_create interceptor waiting for the child thread to start.
Unfortunately this has bad performance characteristics because the OS
scheduler doesn't know the relationship between the parent and child
thread (i.e. the parent thread cannot make progress until the child
thread makes progress) and may make the wrong scheduling decision which
stalls progress.
It turns out that ASan didn't use to block in this interceptor but was
changed to do so to try to address
http://llvm.org/bugs/show_bug.cgi?id=21621/.
In that bug the problem being addressed was a LeakSanitizer false
positive. That bug concerns a heap object being passed
as arg to pthread_create. If:
- The calling thread loses a live reference to the object (e.g. pthread_create finishes and the thread no longer has a live reference to the object).
- Leak checking is triggered.
- The child thread has not yet started (once it starts it will have a live reference).
then the heap object will incorrectly appear to be leaked.
This bug is covered by the lsan/TestCases/leak_check_before_thread_started.cpp test case.
In b029c5101fb49b3577a1c322f42ef9fc616f25bf ASan was changed to block
in pthread_create() until the child thread starts so that arg is
kept alive for the purposes of leaking check.
While this change "works" its problematic due to the performance
problems it causes. The change is also completely unnecessary if leak
checking is disabled (via detect_leaks runtime option or
CAN_SANITIZE_LEAKS compile time config).
This patch does two things:
- Takes a different approach to solving the leak false positive by making LSan's leak checking mechanism treat the arg pointer of created but not started threads as reachable. This is done by implementing the ForEachRegisteredThreadContextCb callback for ASan.
- Removes the blocking behaviour in the ASan pthread_create interceptor.
rdar://problem/63537240
if we at asan_thread.cpp:260 arg is still invisible to lsan, and we can report false leak. So ThreadStatusRunning should be covered as well.