Some interceptors in tsan_libdispatch_mac.cc currently wrongly use TSAN_SCOPED_INTERCEPTOR/ScopedInterceptor. Its constructor can start ignoring memory accesses, and the destructor the stops this -- however, e.g. dispatch_sync can call user's code, so the ignoring will extend to user's code as well. This is not expected and we should only limit the scope of ScopedInterceptor to TSan code.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
It does not look good to me because we lose all the common functionality that we have in ScopedInterceptor ctor/dtor; without some kind of local object we also lose ability to execute any code on interceptor exit (as the result we lose ability to do any kind of "scoped" functionality).
For example, absence of ProcessPendingSignals pretty much means user reports about deadlocks (undelivered signals).
For example, you check in_ignored_lib, but it is never set (normally the flag is set by ScopedInterceptor, which is not executed in this case). So I wonder what is purpose of this check.
Can e.g. dispatch_async execute user code at all?
I think we need something like ScopedUserCallback class that carefully setups thread state for execution of user code, and then dtor undoes that.
There seem to be several other places that we need it: pthread_once seems to call user callback inside of scoped interceptor, dl_iterate_phdr -- the same, pthread_cleanup callbacks called on cleanup inside of a pthread function.
lib/tsan/rtl/tsan_interceptors.cc | ||
---|---|---|
299 ↗ | (On Diff #42868) | in the other patch you added thr->in_interceptor_count |