[llvm-dev] Trouble supressing ASAN reported leaks

Dan Liew via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 16 03:57:14 PST 2015


Hi Alexey,

On 15 December 2015 at 20:20, Alexey Samsonov <vonosmas at gmail.com> wrote:
> Hi Dan,
>
> First of all, sorry for apparently misleading documentation. Currently you
> *can't* use blacklist
> to suppress memory leak reports: blacklist is applied at compile-time, and
> leak detection
> machinery brought up at run-time doesn't know about it.
>
> We should probably fix a documentation, as a first step.

Thanks. If it helps the reason I tried using the compile time
blacklist is that [1] gave the impression that
suppressing ASan reported issues in your "re-compiled code" should be
done using ``-fsanitize-blacklist=``.
I didn't realise that the LeakSanitizer

I think it would be great to fix Clang's documentation here to make it
clear how to suppress each type
of error report from ASan.

As a side note [2] gives the impression you should use mangled names
in a blacklist file as the comment says "use mangled names".
Given that it seems you can use mangled or demangled names it might be
better to say in the comment "You can use either mangled or demangled
names".

> What you can use is:
> 1) Runtime suppression: see
> https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions
>
> You may pass environment variable LSAN_OPTIONS=suppressions=suppr.txt
> and try to specify smth. like
> leak:klee::Array::CreateArray
> or
> leak:lib/Expr/Expr.cpp
> in suppr.txt
>
> 2) You see the error report because LSan is invoked *after* all global
> destructors. So, you have
> std::map<unsigned, std::vector<const Array *> *>
> Array::symbolicArraySingletonMap;
> which contains pointers as values. When the map is destroyed, it's cleared,
> and the allocated objects are
> no longer reachable. As a quick-fix, you can replace a global std::map with
> *a pointer* to global std::map
> which will also never be deleted. In that way all your objects will be
> reachable until the shutdown, and ASan/LSan will be silent.
>
> 3) You may schedule to run leak detection at an earlier point - e.g. as the
> last statement of main(): call __lsan_do_leak_check()
> from <sanitizer/lsan_interface.h>. This would run the leak detection before
> the global destructors, i.e. before std::map is destroyed
>
> Hope that helps.

It helps a lot. These are great answers and probably worthy of being
expanded on slightly and put into the documentation :)

Thanks,
Dan.


More information about the llvm-dev mailing list