Also disables leak checking on a clang crash test, suspected failure
due to LSan's atexit and exit interception behavior.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I'm inclined to just accept this because it looks simple and harmless. Just to be sure, could you point me to any explanation of why LSan is disabled on Darwin in the first place? CC'ing @gottesmm, since he's looked at using LSan on Darwin before.
@kubamracek and I had a discussion about this here: https://reviews.llvm.org/D35443
I think the issue boils down to complexities in objective-C and swift code, and their associated system libraries. LeakSanitizer works well on C++ code (as evidenced by the lack of false positives in the llvm and clang test suites), but I don't personally have the bandwidth to ensure the same goes for objective-C and swift code, particularly due to the fact that many objective-C system APIs are opaque and tough to deal with as someone without access to the source code (stashing pointers in mmap'd pages etc).
LeakSanitizer for Darwin is also fairly new (I finished the implementation within the last couple months), which is why this hasn't been considered before.
There's also a performance/value consideration, LeakSanitizer doesn't impact performance significantly (and has about the same impact on Darwin as it does on Linux), but it still does come with some overhead, and it seems reasonable to allow ASan users to decide whether or not it's a feature they'd like to use.
Looks like the sanitizer configuration is all handled in the top-level llvm lit configuration now, so I'll just merge the crash-vfs-ivfsoverlay.m part of this change, in conjunction with D37781.