canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,334
edits
Performance:Leak Tools: Difference between revisions
move leaksoup up
(→Linux) |
(move leaksoup up) |
||
| Line 1: | Line 1: | ||
== What leak tools do we have? == | == What leak tools do we have? == | ||
When trying to make a particular testcase not leak, I recommend focusing first on the largest object graphs (since these entrain many smaller objects), then on smaller reference-counted object graphs, and then on any remaining individual objects or small object graphs that don't entrain other objects. | |||
=== Leak tools for large object graphs === | === Leak tools for large object graphs === | ||
| Line 12: | Line 14: | ||
==== Cycle Collector Debugging (DEBUG_CC) ==== | ==== Cycle Collector Debugging (DEBUG_CC) ==== | ||
For leaks involving windows, documents, or content nodes (the first two of which show up with leak-gauge), and for many other large graphs of objects that are cycle collected, the cycle collector debugging code can be useful. | |||
The cycle collector debugging code can be enabled by uncommenting the <code>#define DEBUG_CC</code> lines in '''both''' <code>xpcom/base/nsCycleCollector.h</code> and <code>xpcom/glue/nsCycleCollectionParticipant.h</code>. | |||
The cycle collector debugging code relies on being told that cycle-collected objects are expected to be garbage. This is done through the functions <code>nsCycleCollector_DEBUG_shouldBeFreed</code> and <code>nsCycleCollector_DEBUG_wasFreed</code>. When using the cycle collector debugging, it may be helpful to add additional calls to these functions (or maybe even remove some of the existing ones if they add noise). It may also be useful to look only at the cycle collection that happens at shutdown (which can be done by surrounding the call to <code>ExplainLiveExpectedGarbage</code> in <code>nsCycleCollector::Collect</code> with <code>if (aTryCollections > 1)</code>. | |||
When this code is enabled, it prints an explanation of what is keeping alive any objects that are expected to be garbage but are not collected. This means it will print information about what objects from which they are reachable have reference counts that the cycle collector does not know about; you can then debug the leak starting from these objects. It also prints the path from the object keeping this alive to the closest object that it is keeping alive, and if the object keeping things alive is a JS object, it prints all the objects from which that object is reachable. | |||
=== Leak tools for medium-size object graphs === | === Leak tools for medium-size object graphs === | ||
| Line 24: | Line 34: | ||
See below for a detailed description of how to use the refcount balancer effectively. | See below for a detailed description of how to use the refcount balancer effectively. | ||
==== leaksoup ==== | |||
leaksoup is a trace-malloc tool that analyzes the log from trace-malloc's secondary feature, the ability to dump allocations. (See below for more information on using trace-malloc.) trace-malloc's main log is a log that contains information about all allocations and the stacks at which they were allocated and freed, but it also has the ability to dump, at a given time (including shutdown), all the currently live allocations, the stacks at which they were allocated, ''and the contents of the memory''. This last feature allows leaksoup to analyze the graph of live objects and determine which allocations are roots (within that graph, of course -- stack allocations and global variables don't count). Leaksoup also finds sets of objects that are rooted by a cycle (i.e., a set of reference counted objects that own references to each other in a cycle). However, it cannot distinguish between owning and non-owning pointers, which means that non-owning pointers that are nulled out by destructors may show up in leaksoup as cycles. However, despite that, it is probably the easiest way to determine what leak roots are present. | |||
To create a memory dump using trace-malloc, run a build using ''both'' the --trace-malloc and --shutdown-leaks options, for example "./mozilla -P default --trace-malloc=malloc.log --shutdown-leaks=sdleak.log". Ignore the malloc.log file (unless you're interested in other trace-malloc tools, such as [http://mozilla.org/projects/footprint/spaceTrace.html SpaceTrace]). Then run leaksoup over the memory dump (which is a dump of all allocations still live at shutdown) with a command such as ./run-mozilla.sh ./leaksoup sdleak.log > sdleak.html. This generates a ''large'' HTML file as output. | |||
The output of leaksoup begins with all the leak roots, and then lists all the non-root allocations. The roots are either listed as single objects or as strongly connected components (minimal sets of nodes in the graph in which any node is reachable from all other nodes). (A strongly connected component with only one node is listed as a single object.) Any single object listed as a root is really a leak root, and any component listed as a root either (a) contains an object that is a root or (b) contains objects that form an ownership cycle that is a root. | |||
=== Leak tools for simple objects and summary statistics === | === Leak tools for simple objects and summary statistics === | ||
| Line 30: | Line 48: | ||
The trace-malloc code consists of the nsTraceMalloc code in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/lib/ mozilla/tools/trace-malloc/lib/] and the perl scripts and trace-malloc readers in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/ mozilla/tools/trace-malloc/]. It works by overriding / hooking into malloc and free (and related functions) and logging all calls, with stacks. It is probably the best tool we currently have for gathering aggregate memory usage statistics. It is generally more useful for bloat measurement than leak measurement, but it can be used to find leaks. It works on Windows, Linux (x86), and Mac (PPC and Intel). It can be built by checking out mozilla/tools/trace-malloc/ and building with --enable-trace-malloc. | The trace-malloc code consists of the nsTraceMalloc code in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/lib/ mozilla/tools/trace-malloc/lib/] and the perl scripts and trace-malloc readers in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/ mozilla/tools/trace-malloc/]. It works by overriding / hooking into malloc and free (and related functions) and logging all calls, with stacks. It is probably the best tool we currently have for gathering aggregate memory usage statistics. It is generally more useful for bloat measurement than leak measurement, but it can be used to find leaks. It works on Windows, Linux (x86), and Mac (PPC and Intel). It can be built by checking out mozilla/tools/trace-malloc/ and building with --enable-trace-malloc. | ||
==== Boehm GC ==== | ==== Boehm GC ==== | ||
| Line 51: | Line 66: | ||
Apple provides [http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html some tools] for Mac OS X that probably report similar problems to those reported by Purify and Valgrind. | Apple provides [http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html some tools] for Mac OS X that probably report similar problems to those reported by Purify and Valgrind. | ||
=== Leak tools for debugging memory growth that is cleaned up on shutdown === | |||
== Debugging leaks using the refcount balancer == | == Debugging leaks using the refcount balancer == | ||
| Line 146: | Line 163: | ||
Currently the new-style leak stats can be run only on Linux. Hopefully they will work on other platforms soon. They require a build with trace-malloc enabled. | Currently the new-style leak stats can be run only on Linux. Hopefully they will work on other platforms soon. They 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: | This will produce a report like the following: | ||
| Line 155: | Line 170: | ||
Maximum Heap Size: 7751799 bytes | Maximum Heap Size: 7751799 bytes | ||
62095212 bytes were allocated in 391091 allocations. | 62095212 bytes were allocated in 391091 allocations. | ||
== Other References == | == Other References == | ||
* [[Performance:Tools|Performance tools]] | * [[Performance:Tools|Performance tools]] | ||