For example, on Fedora, these are in *-debuginfo RPMs (which are available in yum repositories that are disabled by default, but easily enabled by editing the system configuration).
== Leak statistics on tinderbox ==
=== Reading the old-style leak stats ===
The RLk (nsTraceRefcnt-based) leak stats look like this:
<table style="margin: 1em auto" border="1" width="120"><tr><td style="background: #1d1; text-align: center; font: medium monospace; padding: 2em 1em"><span style="text-decoration:underline; color: #00e; cursor:pointer">L</span> <span style="text-decoration:underline; color: #00e; cursor:pointer">C</span><br>RLk:700B</td></tr></table>
These statistics are collected using nsTraceRefcnt, which as I said above is not very good for aggregate statistics. The action tested is loading of a browser window and a run through the bloat URLs (bloaturls.txt). The RLk (leak) number is the number of bytes of leaks of objects that are logged by nsTraceRefcnt. This is just a subset of objects -- it includes only those objects that use NS_IMPL_ISUPPORTSn and friends or MOZ_COUNT_CTOR and MOZ_COUNT_DTOR. Therefore it doesn't include many of the largest objects, such as string buffers, and it accounts for the size of some other objects incorrectly.
=== Running the old-style leak tests ===
The old-style tests can be run on any standard --enable-debug build, or on any --disable-debug build with --enable-logrefcnt.
==== Mozilla Suite ====
# set the environment variable XPCOM_MEM_LEAK_LOG to leak.log (or XPCOM_MEM_BLOAT_LOG to bloat.log)
# ./mozilla -f bloaturls.txt
# Look at the top line of bloat.log or leak.log for the aggregate statistics (under headers Bytes/Leaked (for leaks) and Objects/Total (for "bloat"), and look at the other lines for the summary of objects.
==== Firefox ====
# load resource:///res/bloatcycle.html and tell the popup blocker to allow popups from it
# Edit the preferences file or use about:config to set the pref "dom.allow_scripts_to_close_windows" to true
# set the environment variable XPCOM_MEM_LEAK_LOG to leak.log (or XPCOM_MEM_BLOAT_LOG to bloat.log)
# ./firefox -no-remote resource:///res/bloatcycle.html
# Look at the top line of bloat.log or leak.log for the aggregate statistics (under headers Bytes/Leaked (for leaks) and Objects/Total (for "bloat"), and look at the other lines for the summary of objects.
=== Reading the new-style leak stats ===
The new-style (nsTraceMalloc-based) leak stats are displayed in the bottom-right panel after clicking on a debug build's "B" and look like this:
<ul>
<li>s: linux-ix-slave35</li>
<li> [http://graphs.mozilla.org/graph.html#tests=[[28,1,6]] Lk: 702KB]</li>
<li> [http://graphs.mozilla.org/graph.html#tests=[[29,1,6]] MH: 32.0MB]</li>
<li> [http://graphs.mozilla.org/graph.html#tests=[[30,1,6]] A: 498010]</li>
<li> check: 31015/0</li>
</ul>
These statistics are generated using trace-malloc. They therefore give accurate aggregate statistics for all heap allocations during the test. Like the old-style leak statistics, the action tested is loading of a browser window and a run through the bloat URLs (bloaturls.txt). The Lk (leak) number is the total number of bytes (not counting any overhead in the allocator) allocated on the heap and not freed over the entire run. This number (as does the number in the old-style leak statistics) includes shutdown leaks, leaks that happen only once for a run of the browser, but there are more here since most shutdown leaks are not of objects logged by nsTraceRefcnt. The MH (max heap) is the number of bytes allocated on the heap at the point during the run when the heap was at its maximum size (again, excluding overhead). The A (allocations) number is the total number of allocations over the run, and is an indicator of a subset of performance rather than an indicator of memory use, although high allocation churn could contribute to fragmentation.
=== Running the new-style leak tests ===
The new-style (trace-malloc) leak stats require a build with trace-malloc enabled.
Build with trace-malloc enabled (--enable-trace-malloc in your mozconfig file). Then, once you have a build, use the same steps as the old-style leak tests, except don't set the environment variables, and instead add the command line options when invoking mozilla or firefox: "--trace-malloc=malloc.log" (or, if you want the shutdown leaks report, also add "--shutdown-leaks=sdleak.log"). Then, to process the log, run "./run-mozilla.sh ./leakstats malloc.log". (Omit the "./run-mozilla.sh" on Windows.)
This will produce a report like the following:
Leaks: 382739 bytes, 3465 allocations
Maximum Heap Size: 7751799 bytes
62095212 bytes were allocated in 391091 allocations.
== Tips ==
