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. >> There's also Leaky, which is documented on the abovementioned wiki >> page. I think it works in tandem with Trace Malloc, and may be a >> candidate for removal as well. > > I don't think leaky is in the tree anymore. (It was once in > tools/leaky/.) Oh, I thought that tools/jprof/leaky.{cpp,h} was it, but it looks like bug 750290 removed it. I guess I can remove the references from the MDN page. (I can probably remove Purify from that page, too!) Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
