http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #18 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Joost VandeVondele from comment #17) > (In reply to Sergey Matveev from comment #16) > > > > Under the current behavior -fsanitize=address,leak is equivalent to > > -fsanitize=address. > > > > We've considered other options, such as making -fsanitize=leak change the > > default run-time behavior (currently the ASan runtime always has leak > > detection runtime-disabled by default, whereas the standalone LSan runtime > > always has it enabled). But we never arrived at anything sensible. > > From my 'user perspective' it would be great if -fsanitize=leak would > perform leak checking by default (i.e. remove the requirement to export > ASAN_OPTIONS="detect_leaks=1"). That's what -fsanitize=leak does in clang. > At that point it would be natural to expect that -fsanitize=address,leak > just enables the leak checking by default, while -fsanitize=address might > not. That's not so trivial to implement and I don't like anything non-trivial :) The trivial solution is to have lsan on by default in asan -- we are working on that. > > Out of curiosity, is there a runtime performance difference in using -llsan > or -lasan for leak checking only ? I don't think we've measured pure-lsan slowdown, but I expect it to be small. asan/lsan bring in a different allocator (malloc/free). We tried to make it very fast and our measurements show that's it is close to tcmalloc performance (but a bit more greedy in memory). It also performs stack unwind on every malloc, so on malloc-intensive apps you may see some small slowdown.
