On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
Details
Diff Detail
Event Timeline
Thanks for adding the check this is very useful!
Looks like this would work for all sanitizers, including ASan. Is that correct?
lib/sanitizer_common/sanitizer_mac.cc | ||
---|---|---|
636 | Wouldn't if (info.dli_fbase != info_pthread_create.dli_fbase) work as well? Seems easier to read. | |
test/tsan/Darwin/dlopen.cc | ||
13 | I really think this would be better in the lit.cfg files (and then dealt with via REQUIRES/UNSUPPORTED), instead of having tests depend on more and more available executables/specific shells. |
lib/sanitizer_common/sanitizer_mac.cc | ||
---|---|---|
636 | It seems to work, but I don't think it's guaranteed by the API. Since we're doing this once only, it's not a big deal performance-wise, and I think readability is fine here – we *are* actually comparing two strings. |
LGTM
test/tsan/Darwin/dlopen.cc | ||
---|---|---|
30 | I'm curious how does the dynamic linker behave in the presence of another main(). |
Changed the test to detect OS X version in lit.cfg instead, and to produce a regular shared library instead of two executables with two main functions.
I'm curious how does the dynamic linker behave in the presence of another main().
Maybe rename it to foo() just to be sure?
I believe this is supposed to work fine because of OS X two-level namespaces, and because I'm performing the dlopen/dladdr lookup in a single module (so there is no clash between the symbols). Anyway, I changed the test to generate a regular shared library with a foo symbol.
I had to revert this and make more changes, but I can't reopen this revision, so I instead submitted a new patch to http://reviews.llvm.org/D18212.
Wouldn't if (info.dli_fbase != info_pthread_create.dli_fbase) work as well? Seems easier to read.