==== Cycle collector and JavaScript heap dump ====
The cycle collector heap dump is useful for figuring out why the cycle collector is keeping an object alive. These can either be manually or automatically generated. They can be generated in both debug and non-debug builds.
To manually generate a CC dump, go to about:memory and use the buttons under "Save GC & CC logs." "Save concise" will generate a smaller CC log, "Save verbose" will provide a more detailed CC log. This creates a file named cc-edges-NNNN.log and writes a dump of the heap known to the cycle collector, which includes JS objects and also native C++ objects that participate in cycle collection, to the file. It will also log the contents of the Javascript heap to a file named gc-edges-NNNN.log. One can override the default location of the log files by setting the MOZ_CC_LOG_DIRECTORY environment variable. http://people.mozilla.com/~mleibovic/cc-dump.xpi is an addon for Android Firefox which uses that to save files to /sdcard. The code for this addon is available on [https://github.com/leibovic/skeleton-addon-fxandroid/tree/cc Github]. By default, the file is created in some temp directory, and the path to the file is printed to the Error Console. To log every cycle collection, set the MOZ_CC_LOG_ALL environment variable (XPCOM_CC_LOG_ALL in 29 and earlier). To log only shutdown collections, set MOZ_CC_LOG_SHUTDOWN (XPCOM_CC_LOG_SHUTDOWN in 29 and earlier). To make any shutdown CCs AllTraces() at shutdown, set MOZ_CC_ALL_TRACES_AT_SHUTDOWN (XPCOM_CC_ALL_TRACES_AT_SHUTDOWN in 29 and earlier). The latter two These are useful for debugging shutdown leaks. In 30 and later, set the environment variable MOZ_CC_LOG_THREAD to main to only log main thread CCs, or to worker to only log worker CCs. The default value is all, which will log all CCs. 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. Most big leaks include an nsGlobalWindow, so that's a good class to try if you don't have any better idea. 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/g find_roots for JS] documented on the gc-edges file generated by the CC dump. ===== Addons for creating and analyzing cycle collector graphs =====* Simple, ugly, yet rather powerful [https://bugzilla.mozilla.org/show_bug.cgi?id=726346 about:cc]* Prettier but a bit slower [https://addonsdeveloper.mozilla.org/en-US/firefoxdocs/addonMozilla/cycle-collector-analyzerPerformance/?src=ss about:ccdumpGC_and_CC_logs MDN].
=== Leak tools for medium-size object graphs ===
