<div dir="ltr">Hi Dan,<div><br></div><div>First of all, sorry for apparently misleading documentation. Currently you *can't* use blacklist</div><div>to suppress memory leak reports: blacklist is applied at compile-time, and leak detection</div><div>machinery brought up at run-time doesn't know about it.</div><div><br></div><div>We should probably fix a documentation, as a first step.</div><div><br></div><div>What you can use is:</div><div>1) Runtime suppression: see <a href="https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions">https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions</a></div><div><br></div><div>You may pass environment variable <span style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;line-height:inherit;color:rgb(51,51,51);background-color:transparent">LSAN_OPTIONS=suppressions=suppr.txt</span></div><div>and try to specify smth. like</div><div>leak:klee::Array::CreateArray<br></div><div>or</div><div>leak:lib/Expr/Expr.cpp</div><div>in suppr.txt</div><div><br></div><div>2) You see the error report because LSan is invoked *after* all global destructors. So, you have</div><div>std::map<unsigned, std::vector<const Array *> *> Array::symbolicArraySingletonMap;</div><div>which contains pointers as values. When the map is destroyed, it's cleared, and the allocated objects are</div><div>no longer reachable. As a quick-fix, you can replace a global std::map with *a pointer* to global std::map</div><div>which will also never be deleted. In that way all your objects will be reachable until the shutdown, and ASan/LSan will be silent.</div><div><br></div><div>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()</div><div>from <sanitizer/lsan_interface.h>. This would run the leak detection before the global destructors, i.e. before std::map is destroyed</div><div><br></div><div>Hope that helps.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 15, 2015 at 10:58 AM, Dan Liew via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I'm currently trying to find and fix memory leaks (compiling with<br>
``-fsanitize=address``) in the KLEE tool [1] an having found some<br>
leaks and I'm having trouble suppressing them.<br>
<br>
I'm trying to suppress them using the<br>
``-fsanitize-blacklist=blacklist.txt`` option as documented at<br>
[2]. I'm using Clang 3.7 ( Arch Linux package 3.7.0-6).<br>
<br>
The sort of reported leaks I see are<br>
<br>
```<br>
==9912==ERROR: LeakSanitizer: detected memory leaks<br>
<br>
Direct leak of 24 byte(s) in 1 object(s) allocated from:<br>
#0 0x4df4a0 in operator new(unsigned long)<br>
(/home/dsl11/dev/klee/klee/build_asan/unittests/Expr/Release+Asserts/ExprTests+0x4df4a0)<br>
#1 0x4f76e1 in<br>
klee::Array::CreateArray(std::__cxx11::basic_string<char,<br>
std::char_traits<char>, std::allocator<char> > const&, unsigned long,<br>
klee::ref<klee::ConstantExpr> const*, klee::ref<klee::ConstantExpr><br>
const*, unsigned int, unsigned int)<br>
/home/dsl11/dev/klee/klee/src/lib/Expr/Expr.cpp:522:16<br>
#2 0x4e30d5 in (anonymous<br>
namespace)::ExprTest_ConcatExtract_Test::TestBody()<br>
/home/dsl11/dev/klee/klee/src/unittests/Expr/ExprTest.cpp:34:25<br>
#3 0x526410 in testing::Test::Run()<br>
(/home/dsl11/dev/klee/klee/build_asan/unittests/Expr/Release+Asserts/ExprTests+0x526410)<br>
<br>
...<br>
<br>
Indirect leak of 80 byte(s) in 1 object(s) allocated from:<br>
#0 0x4df4a0 in operator new(unsigned long)<br>
(/home/dsl11/dev/klee/klee/build_asan/unittests/Expr/Release+Asserts/ExprTests+0x4df4a0)<br>
#1 0x4f75ce in<br>
klee::Array::CreateArray(std::__cxx11::basic_string<char,<br>
std::char_traits<char>, std::allocator<char> > const&, unsigned long,<br>
klee::ref<klee::ConstantExpr> const*, klee::ref<klee::ConstantExpr><br>
const*, unsigned int, u<br>
nsigned int) /home/dsl11/dev/klee/klee/src/lib/Expr/Expr.cpp:506:25<br>
#2 0x4e2ff3 in (anonymous<br>
namespace)::ExprTest_ConcatExtract_Test::TestBody()<br>
/home/dsl11/dev/klee/klee/src/unittests/Expr/ExprTest.cpp:32:24<br>
#3 0x526410 in testing::Test::Run()<br>
(/home/dsl11/dev/klee/klee/build_asan/unittests/Expr/Release+Asserts/ExprTests+0x526410)<br>
```<br>
<br>
The source of the trouble is this static object.<br>
<br>
```<br>
std::map<unsigned, std::vector<const Array *> *><br>
Array::symbolicArraySingletonMap;<br>
```<br>
<br>
Neither the ``std::vector<const Array*>`` pointers or the ``const<br>
Array`` pointers are being freed. Sure this code is bad (don't blame<br>
me, I didn't write it), but I want to skip over this leak to find more<br>
interesting issues.<br>
<br>
I can't seem to suppress it though. I've tried putting the following<br>
in the ``blacklist.txt`` file<br>
<br>
* Explicitly naming the source file, like this<br>
<br>
src:/home/dsl11/dev/klee/klee/src/lib/Expr/Expr.cpp<br>
<br>
* Naming the function where the leak originates (demangled)<br>
<br>
fun:klee::Array::CreateArray<br>
<br>
* Naming the function where the leak originates (mangled)<br>
<br>
fun:_ZN4klee5Array11CreateArrayERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmPKNS_3refINS_12ConstantExprEEESD_jj<br>
<br>
* Naming the global (demangled)<br>
<br>
global:klee::Array::symbolicArraySingletonMap<br>
<br>
* Naming the global (mangled)<br>
<br>
global:_ZN4klee5Array25symbolicArraySingletonMapE<br>
<br>
<br>
None of these succeed in suppressing the error. Does anyone have any<br>
idea what I'm doing wrong?<br>
<br>
Note I'm also using a fairly new build of libstdc++ which is using a<br>
new ABI [3]. I'm not sure if this would cause problems.<br>
<br>
[1] <a href="https://github.com/klee/klee" rel="noreferrer" target="_blank">https://github.com/klee/klee</a><br>
[2] <a href="http://clang.llvm.org/docs/AddressSanitizer.html#suppressing-errors-in-recompiled-code-blacklist" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/AddressSanitizer.html#suppressing-errors-in-recompiled-code-blacklist</a><br>
[3] <a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html</a><br>
<br>
Thanks,<br>
Dan.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div>