Confirm
557
edits
Changes
add some description of how to find leaks using the CC dump
==== Cycle collector heap dump ====
Then evaluate this expression:
garbageCollect(Components.classes["@mozilla.org/cycle-collector-logger;1"]
.createInstance(Components.interfaces.nsICycleCollectorListener))
Nightly builds before 2012 defaulted to all traces, newer builds logs the
* Firefox 12 (including nightly builds after 2012-01-02) creates the file in the temp directory and prints the path to the file to the Error Console.
* Older builds created the file in Firefox's current working directory (usually the current working directory where Firefox was started). That meant that on Windows 7 and Vista, you typically had to run Firefox as Administrator to create the file.
To automatically generate a cycle collector dump, set gAlwaysLogCCGraphs to true in xpcom/base/nsCycleCollector.cpp. This will make every cycle collection produce a dump. This is primarily useful for debugging shutdown leaks.
To analyze a cycle collector dump, you need the scripts from [https://github.com/amccreight/heapgraph/tree/master/cc Github]. The relevant scripts are find_roots.py and parse_cc_graph.py (which is called by find_roots). Calling find_roots on a CC file with a specific object or kind of object will produce paths from rooting objects to the specified objects. To fix a leak, the next step is to figure out why the rooting object is alive. For a C++ object, you need to figure out where the missing references are from. For a JS object, you need to figure out why the JS object is reachable from a JS root. For the latter, you can use the corresponding [https://github.com/amccreight/heapgraph/tree/master/gc find_roots for JS] on the gc-edges file generated by the CC dump.
=== Leak tools for medium-size object graphs ===
