Wildcard for suppressing (<unknown module>) from LeakSanitizer errors.

[gnzlbg]

Is there a wildcard to suppress errors marked as () ? Like:

=================================================================
==33408==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 232 byte(s) in 1 object(s) allocated from:
    #0 0x8ba15b in __interceptor_malloc /home/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x7fe004c13ad4  (<unknown module>)

Direct leak of 25 byte(s) in 2 object(s) allocated from:
    #0 0x8ba15b in __interceptor_malloc /home/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x7fe010ac7bd0  (<unknown module>)

[kcc]

I suspect you compile w/o -fno-omit-frame-pointer and thus your stack trace is broken. Fix that.

[gnzlbg]

@kcc I'm compiling with -fno-omit-frame-pointer.

These are my flags (hint: -fno-omit-frame-pointer is one of the last ones):

clang++
-DMPICH_IGNORE_CXX_SEEK -DQT_CORE_LIB -DQT_GUI_LIB
-fsanitize=address,integer,undefined -DRANGES_SUPPRESS_IOTA_WARNING
-DFMT_HEADER_ONLY -DEIGEN_FAST_MATH -DEIGEN_NO_AUTOMATIC_RESIZING
-DHM3_ENABLE_VTK -g -isystem range-v3/include
-isystem /json/src -isystem spdlog/include -isystem Eigen3 -isystem openmpi-1.8.7/include
-I/ParaView-4.4.0/include/paraview-4.4 -I/usr/include/python2.7 -isystem
/usr/include/QtGui -isystem /usr/include/QtCore -I/include
-std=c++14 -Wshadow -Wunused -Wunused-function -Wunused-label -Wunused-parameter
-Wunused-value -Wunused-variable -Wall -Wextra -Wdeprecated -Wdocumentation
-Wcomment -Wpedantic -Wstack-protector -Wstrict-aliasing=2 -Wstrict-overflow=5
-Wdisabled-optimization -Winline -Wreturn-type -Wcast-align -Wcast-qual
-Wsign-compare -Wsign-promo -Wformat=2 -Wformat-nonliteral -Wformat-security
-Wformat-y2k -Wmissing-braces -Wmissing-field-initializers -Woverloaded-virtual
-Wchar-subscripts -Wfloat-equal -Wpointer-arith -Winvalid-pch -Wimport
-Winit-self -Wredundant-decls -Wpacked -Wparentheses -Wsequence-point -Wswitch
-Wswitch-default -Wtrigraphs -Wuninitialized -Wunknown-pragmas
-Wunreachable-code -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings
-Wno-attributes -Wunneeded-internal-declaration -fdiagnostics-show-template-tree
-ftemplate-backtrace-limit=0 -D__extern_always_inline=inline
-fno-omit-frame-pointer -g0 -O0 -fno-inline -fstack-protector-all -o
CMakeFiles/test.hm3.tree.tree_3d.dir/hm3/tree/tree_3d.cpp.o -c
test.cpp 

EDIT: I'm using clang-3.8 tip-of-trunk in case that helps, and as can be seen above i'm passing -fsanitize=address,integer,undefined.

[kcc]

Another possible reason is that the leak happens inside a pre-build library which was built w/o -fno-omit-frame-pointer. Try env. var. ASAN_OPTIONS=fast_unwind_on_malloc=0 (note: this is slow)

[gnzlbg]

@kcc is the leak sanitizer enabled by default? I just re-read my comment and triple-checked it, and... I'm not passing -fsanitize=...,leak.

Another possible reason is that the leak happens inside a pre-build library which was built w/o -fno-omit-frame-pointer.

Yes, this is what I suspect as well, but in general I cannot do anything about that (e.g. I depend on vendor dependent MPI libraries that I cannot control).

Try env. var. ASAN_OPTIONS=fast_unwind_on_malloc=0 (note: this is slow)

I will try this and let you know how it goes.

[kcc]

yes, lsan is on by default as part of asan. You can disable it completely with ASAN_OPTIONS=detect_leaks=0

Closing. Please reopen or contact address-sanitizer@googlegroups.com if the problem persists.

[gnzlbg]

ASAN_OPTIONS=fast_unwind_on_malloc=0 removes all the leaks with (<unknown module>) I was having, but yes, it is slow.

[kcc]

Note that fast_unwind_on_malloc=0 is often too slow to be usable.

[gnzlbg]

@kcc do you have any other suggestion? I really cannot recompile those libraries.

[kcc]

No good suggestion, sorry.

fast_unwind_on_malloc=0 is not much slower than the default fast_unwind_on_malloc=1, just use that. The slowdown depends on how many malloc calls you have in run-time. Otherwise, run lsan once to fix leaks that you can fix and disable lsan in regular runs.

Maybe if you can show me the stack traces (with fast_unwind_on_malloc=0) I'll have more ideas