Page MenuHomePhabricator

[ASan][Darwin] Ensure we always register GCD worker threads
ClosedPublic

Authored by yln on May 24 2022, 9:14 PM.

Details

Summary

In rare cases, our interceptors for dispatch_async (and friends) are
not enough to reliably observe GCD worker thread creation. When we
later find a bug (via interceptors) on a thread that hasn't been
registered we crash during report generation because we never set the
current thread context (via SetCurrentThread()).

This change adds a "pthread introspection hook", to guarantee ASan
initialization for GCD worker threads. This code is similiar to what we
are already doing for TSan, so I tried to factor out the common code.

Diff Detail

Event Timeline

yln created this revision.May 24 2022, 9:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 24 2022, 9:14 PM
yln requested review of this revision.May 24 2022, 9:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 24 2022, 9:14 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
wrotki accepted this revision.Jul 21 2022, 3:10 PM

LVGTM - very DRY :)

This revision is now accepted and ready to land.Jul 21 2022, 3:10 PM
delcypher accepted this revision.Jul 22 2022, 6:51 AM

Really nice refactor. LGTM.

delcypher added inline comments.Jul 22 2022, 6:54 AM
compiler-rt/lib/asan/asan_mac.cpp
167

Sidenote: Should we eventually move (i.e. not in this patch) to this mechanism to register all threads (i.e. not just GCD worker threads)? It might be nice if there was only one way we registered threads rather than two.

This revision was landed with ongoing or failed builds.Jul 22 2022, 1:29 PM
This revision was automatically updated to reflect the committed changes.
yln marked an inline comment as done.Jul 22 2022, 1:48 PM
yln added inline comments.
compiler-rt/lib/asan/asan_mac.cpp
167

I thought about this as well. There is 2 questions: "Should we do it?" and "Is it worth it?".

For the first question, I think the main argument for it is:

  • Consistency: it would be nice to have one place/code path that does it

But my feeling is the the argument against it is stronger:

  • Minimize differences with other platforms. When other things/places in the sanitizer make assumptions then "mostly default + Apple corner cases" is probably a better situation then "Apple uses different mechanism".

Both options aren't optimal for maintenance, but I feel like the 2nd one is lower risk.