Hacker News Reader

It can detect more errors and you don't need to recompile anything.

Generally asan+msan detect more errors, and some quite significant ones. For design reasons, valgrind cannot detect most stack oob bugs. The only issue with msan is that it's a bit trickier to use, particularly if you have lots of dependencies.

Both approaches have their right to exist, but I have been preaching to people that valgrind does not find all memory safety bugs that modern tools can find, and they should be testing with sanitizers. I still experience that many people are not aware of asan+co and only know valgrind.

How well does ASAN cope when the libraries your application uses aren't compiled with ASAN? Does it cause false negatives or false positives?

ASan will have false negatives on the memory accesses performed in the code which isn't compiled with ASan. It works fine, otherwise. FWIW, UBSan (-fsanitize=undefined) follows the same rule. For this reason it's common to combine them and build once with -fsanitize=address,undefined. Don't forget to pass that while linking too.

ThreadSanitizer requires that all code with atomic accesses be instrumented.

MemorySanitizer requires that all code which writes to a byte in memory be instrumented.

Reply on news.ycombinator.com