canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,334
edits
Performance:Leak Tools: Difference between revisions
→Cycle Collector Debugging (DEBUG_CC)
| Line 22: | Line 22: | ||
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. | 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. | ||
==== JavaScript heap dump ==== | |||
Setting the <code>XPC_SHUTDOWN_HEAP_DUMP</code> environment variable to a file name will cause XPConnect to, at shutdown, dump a log to that file explaining why all remaining JS objects are still alive. This may be sufficient to debug some JS-related leaks without the full rebuild required by DEBUG_CC. It also shows more information about reachability, since it shows property names for all connections. | |||
=== Leak tools for medium-size object graphs === | === Leak tools for medium-size object graphs === | ||
| Line 34: | Line 38: | ||
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 40: | Line 52: | ||
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 165: | Line 174: | ||
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]] | ||