[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #16 from Sergey Matveev --- (In reply to Kostya Serebryany from comment #11) > > Easily doable of course, but we should create liblsan as shared > > library in that case too. What combination of those do you allow? I mean, > > is > > -fsanitize=address,leak allowed (and only links -lasan?), etc.? > > Sergey, please answer here (and make sure this is documented) 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.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #31 from Sergey Matveev --- (In reply to Kostya Serebryany from comment #30) > lsan's allocator clears all memory using internal_memset, which is damn > slow. (sets on byte at a time) > > asan's allocator doesn't do that (it sets first 4K bytes of allocated region > with garbage using the REAL fast memset) > > I think the right solution is to finally implement *fast* internal_memset. > We'll do that. > > Sergey, can this difference between asan and lsan allocators cause > false negatives/positives in lsan? It can cause a false negative if there's a stale pointer outside of those 4k. But in practice 4k ought to be enough for anybody. I think standalone LSan should support the max_alloc_fill_size flag. I'll also change it to use real memset.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #33 from Sergey Matveev --- (In reply to Kostya Serebryany from comment #32) > > I think standalone LSan should support the max_alloc_fill_size flag. > > Mmm. Maybe... > max_alloc_fill_size in asan is there primarily to protect from filling huge > allocations coming from LargeMmapAllocator Ok, if we can afford to clear all small chunks entirely, we don't need that flag since the large chunks are already cleared by mmap. Apropos, the common allocator currently clears memory even for large chunks, which needs to be fixed. > >> I'll also change it to use real memset. > > Using REAL(memset) in sanitizer_common may not be a great idea. > (first of all, you can't do it easily) What I meant is that LSan could clear the memory instead of relying on the sanitizer allocator to do it. Then we'd only have to call memset() from the LSan runtime. How soon will internal_memset() be on par with the library implementation?
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #37 from Sergey Matveev --- I've patched LSan to use the real memset(). At least on my machine this brought no performance improvement compared to kcc's latest change (just FYI - not trying to make any point). As of now, LSan will still clear out the entire small chunk (which can be up to 128KB in size), compared to a default of just the first 4KB in ASan. I'm undecided as to whether this is worth changing.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #38 from Sergey Matveev --- (In reply to Jakub Jelinek from comment #28) > Author: jakub > Date: Fri Nov 22 21:13:08 2013 > New Revision: 205290 It looks like you use dynamic linking by default. The last time I checked, leak detection (in both ASan and standalone LSan) didn't work 100% correctly with dynamic linking. Should be easy to fix by giving one of the interceptors a stronger visibility.
[Bug driver/65639] New: -nostdlib/-nodefaultlibs should not affect ASan runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639 Bug ID: 65639 Summary: -nostdlib/-nodefaultlibs should not affect ASan runtime Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: earthdok at google dot com CC: jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, samsonov at google dot com In GCC trunk, if -nostdlib/-nodefaultlibs is passed together with -fsanitize=address, the ASan runtime is not linked. Clang had the same behavior briefly but ended up reverting to the old behavior (i.e. those flags do not affect the ASan runtime): http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141020/117217.html https://code.google.com/p/address-sanitizer/issues/detail?id=344 One use case where GCC's behavior is problematic is building an ASan-instrumented glibc. Some executables are linked with -nostdlib and explicitly linked against the just-built libc.so.6; -fsanitize=address causes those build steps to fail due to unresolved ASan symbols.
[Bug driver/65639] -nostdlib/-nodefaultlibs should not affect ASan runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639 --- Comment #2 from Sergey Matveev --- This is also discussed in the email thread following the clang commit: https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg106622.html You could say that by passing -fsanitize=address at link time, we explicitly tell clang to link in the sanitizer runtime. So -nodefaultlibs shouldn't negate -fsanitize=address much as it wouldn't negate -lc. I think this was the logic behind the final decision. While -l:libasan.a helps, it must be applied to non-shared objects only, which is more awkward than just adding -fsanitize=address.
