[cfe-users] Trouble adding leak sanitizer suppressions with --fsanitizer-blacklist option

[Andrew C. Morrow]

On Fri, Oct 3, 2014 at 6:28 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
> Hi Andrew,
>
> Blacklist file and suppressions file are different, and have different
> format:
> Here's the description of blacklist file format for ASan:
> http://clang.llvm.org/docs/AddressSanitizer.html#blacklist
>
> Blacklist file is only used during the compilation. Compiler just doesn't
> insert ASan checks for blacklisted items, so
> if you have a bug in a blacklisted function, its code will not have ASan
> checks, and this the bug has no chance of being reported in runtime.
>
> Suppression file is used in runtime - when the error actually happens, it is
> matched against the suppressions, and is not reported in case of a match.

I see. That makes sense, but maybe wasn't very clear from the documentation.

>
> Note that:
> 1) There's no way to "suppress" ASan errors. Currently all ASan errors are
> fatal and immediately crash your executable. This is done on purpose -
> we believe ASan-detected errors are critical and definitely needs to be
> fixed, and making the errors unrecoverable improves tool performance
>

Understood, and I like this behavior of ASan. In this situation though
the only thing I need to suppress are leaks, the ASan errors have
already been scrubbed out.

> 2) There's currently no way to "blacklist" memory leaks. They can only be
> suppressed. The reason is - LSan doesn't modify the program at compile time
> at
> all. It just replaces the memory allocator at link time, plugging in custom
> functions instead of malloc/free from standard library. So, in order to
> propagate
> blacklist contents to LSan, we'd have to bake it into the executable, which
> we don't really want to do.
>
> Now this problem is solved with __lsan_default_suppressions, so I don't
> really know what to advise you, assuming you're bound to the old version of
> Clang.
>

Yes __lsan_default_suppressions is really nice. I actually started
with that in my dev environment which uses clang-3.5 and it worked
very well, but for the moment my solution needs to support clang-3.4
as well.

LSAN_OPTIONS it is...

Thank you for the detailed explanations,
Andrew