0

I'm linking a 3rd party library which uses boost. I get the following error:

==1068324==ERROR: AddressSanitizer: alloc-dealloc-mismatch (INVALID vs operator delete) on 0x603000000688
    #0 0x7fce33fb6ce7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
    #1 0x563b51fd5fde in boost::filesystem::path::~path() /home/ventsyvelev/.conan/data/boost/1.80.0/_/_/package/dc8aedd23a0f0a773a5fcdcfe1ae3e89c4205978/include/boost/filesystem/path.hpp:132
    #2 0x7fce32c1b494 in __run_exit_handlers stdlib/exit.c:113
    #3 0x7fce32c1b60f in __GI_exit stdlib/exit.c:143

It seems LeakSanitizer is reporting an error in boost. I would like to suppress it but unfortunately the documentation is not clear on how to do that.

For one, LeakSanitizer and AddressSanitizer seems to using 2 different environmental variables for options, and the suppression syntax seem to be different as well. From the documentation for ASAN:

ASAN_OPTIONS=suppressions=MyASan.supp

Use the following format to specify the names of the functions or libraries you want to suppress. You can see these in the error report. Remember that the narrower the scope of the suppression, the more bugs you will be able to catch.

interceptor_via_fun:NameOfCFunctionToSuppress
interceptor_via_fun:-[ClassName objCMethodToSuppress:]
interceptor_via_lib:NameOfTheLibraryToSuppress

LeakSanitizer however:

However, if you built with -fsanitize=leak, put them in LSAN_OPTIONS instead (and use LSAN_SYMBOLIZER_PATH to pass the symbolizer path).

You can instruct LeakSanitizer to ignore certain leaks by passing in a suppressions file. The file must contain one suppression rule per line, each rule being of the form leak:. The pattern will be substring-matched against the symbolized stack trace of the leak. If either function name, source file name or binary file name matches, the leak report will be suppressed.

This seems to suggest that -fsanitize=address and -fsanitize=leak are mutually exclusive. But I define them both in my Cmake file.

Also, I tried a various combination of syntax-es in the suppression file and they all fail.
Using the ASAN syntax results in AddressSanitizer: failed to parse suppressions

Using LSAN syntax (leak:boost for example) doesn't see to produce any visible results, maybe the rule is being ignored?

I tried alloc-dealloc-mismatch:boost and that fails to parse.

Any idea how to tell it to ignore that particular error? I don't want to have to turn off alloc-dealloc-mismatch checking completely as some posts seem to suggest.

ventsyv
  • 3,316
  • 3
  • 27
  • 49
  • Are you assuming it is somehow a false-positive? Why? – sehe Feb 21 '23 at 22:49
  • Yeah Id assume that boost would be clean here, and whatever global that is getting destructed there has something wrong with it. – Mike Vine Feb 21 '23 at 23:04
  • My concern is that none of the parties have to be in the wrong. It could be the sanitizer informing you that different parts of the application were linked to different versions of (boost/runtime) libraries. That seems a problem you want to fix. It really seems unlikely to me that a library could somehow get new/delete to mismatch for something like `boost::filesystem::path` - think about it. – sehe Feb 22 '23 at 00:02
  • 3
    Just because it's "reporting an error in boost", in the stack trace, means very little. The memory leak/corruption can be anywhere, and be caused by anything. It only gets tripped up here. By scribbling over some carefully chosen pointers I could easily trigger a memory error getting reported in `std::string`'s destructor. `std::string` will be completely innocent. The bug will be in my own code. – Sam Varshavchik Feb 22 '23 at 00:10
  • I'm linking a 3rd party lib, without actually using it. Without that library no memory leaks are detected. It's pretty clear the problem is not in my code. I need to unblock in the meantime. – ventsyv Feb 22 '23 at 14:34
  • This is at build time so it's not memory corruption. I'm using all C++17 and no raw pointers anyway. – ventsyv Feb 22 '23 at 14:50
  • Linking conflicting versions of libraries can be enough to cause UB. I've never seen this occur as a false positive. – sehe Feb 22 '23 at 21:55
  • @sehe We are using conan to manage the dependencies. I don't see how we can have conflicting libraries. – ventsyv Mar 01 '23 at 18:02

0 Answers0