http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #32 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Sergey Matveev from comment #31) > (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. Some improvement made in http://llvm.org/viewvc/llvm-project?view=revision&revision=195549 Will reach gcc with the next merge. > > > > 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. lol :) > > 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 >> 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) Anyway, my change above improved the situation quite a bit (2x on a synthetic test)
