[PATCH] D35443: Enable 64-bit Darwin LeakSanitizer by default on AddressSanitizer builds

[Kuba (Brecka) Mracek via Phabricator via llvm-commits]

kubamracek added a comment.

Thanks for working on this!

> LSan doesn't actually report a false positive leak there, it just omits some of the crash dump printout.
>  What's the preferred way to handle these failures?

Why does it omit some of the output?  That sounds weird.  In any case, for clang test failures, if we think the value of running LSan is high enough already, we can just disable the two failing tests under ASan/LSan.  I don't have a problem with that.

What is controversial is turning on `detect_leaks=1` for everyone who currently uses ASan.  Clang/LLVM is not a representative codebase and having no false positives on Clang/LLVM doesn't mean we don't have problems elsewhere.  We (Apple) have many users of ASan on various codebases written in C, C++, Objective-C and also Swift.  I mentioned Swift in particular because the language runtime plays a lot of tricks of pointer bitmasking and reusing pointer bits to store data — these things can easily cause false positives.  Maybe this concern is

Secondly, not everyone cares about leaks.  There are programs that are short-lived and their authors simply do not see leaks as a serious problem.

The way I see it, I'd prefer users to opt in to use LSan.  If a project wants to detect leaks, it can just set `ASAN_OPTIONS=detect_leaks=1`.  Do you have a strong reason why `detect_leaks=1` should be the default?  (Besides parity with Linux.)

Setting `detect_leaks=1` in the ASan test suite is, of course, a good thing to do in any case.


https://reviews.llvm.org/D35443