On Mon, May 19, 2014 at 05:07:44PM -0700, Nicholas Nethercote wrote: > On Mon, May 19, 2014 at 3:05 PM, L. David Baron <dba...@dbaron.org> wrote: > >> Do we still need Trace Malloc? > > > > Are you talking about removing it from the debug builds done on our > > infra, or removing it from the tree? > > I'm aiming for the latter, though the former is a reasonable first step :) > > > I think the former is fine; > > I'd like to know more about the memory graph analysis abilities of > > ASAN before being ok with the latter. > > > > (It was enabled because we used to track shutdown leak metrics and > > some other metrics, but when we switched to tracking > > performance/memory metrics from graphs to tracking them via > > regression notices, regression notices weren't added for those > > measurements, so they just kept regressing without people noticing. > > At some point we then stopped running them because nobody was > > looking at them. I wouldn't mind having that metric tracked again > > in some way because it does catch some real leak regressions in > > addition to shutdown leaks.) > > Andrew McCreight is working on getting LSAN enabled by default on TBPL > (bug 976414). He's already found a bunch of leaks using it; see the > blocking bugs. LSAN's docs are here: > https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer. > There's not much info on how it works, though I suspect it's extremely > similar to how Valgrind's leak checking works, which is described in > some detail here: > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks > > If you're still concerned, porting this feature of Trace Malloc to DMD > is an option. But in general, tools like Valgrind and ASAN/LSAN do a > better job of leak detection than simple malloc replacement tools like > Trace Malloc, because they are able to do a conservative scan of > addressable memory to find pointers. This means they can distinguish > truly unreachable blocks from blocks that are still reachable but we > didn't bother freeing. In practice, the number of blocks in the latter > category is huge, and IME tools that can't distinguish the two cases > are very difficult to use.
OTOH, *SAN tools are only running on Linux, and thus won't find any leaks that come from platform-dependent code. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
