Subscribe to RSS Feed

I have recently spent some time hunting down memory leaks in Firebug and the most successful way I have found so far has been analyzing CC (Cycle Collector) object graph - graph of objects that are cycle collected.

The particular memory leak I have been looking for is called a zombie compartment. In my case, there is a document living in the memory even if the parent tab has been closed long time ago. Something is still referencing that document object so, it can't be released. The goal here is usually to find that referent. And this is when the CC heap debugging comes to rescue.

The rest of this post describes my extension CCDump that allows to dynamically analyze CC object graph.

Manual Analysis

CC heap dump log can be created manually using the following script (you can evaluate it in Firefox Error Console).


A file, something like: cc-edges-1.7104.log is created and path to it logged into the Error Console. This file contains text representation of the entire graph and you can use any text editor to search it.

Manual creation and search is tedious and you can easily spent hours and hours by repeating manual steps: open Firefox, reproduce a memory leak, execute the script to get the log, open the text file, search for zombie document, search for related objects, etc. - without any satisfying results.

That's why I decided to automate the entire process. Thanks to Olli Pettay who implemented a new API (introduced in Firefox 13, current Nightly) that allows to dynamically analyze the CC object graph from within an extension.

Dynamic Analysis

I implemented a bootstrapped (restart-less) extension that can be installed at the moment when you are experiencing a zombie compartment in your browser session - and immediately (without restart) analyze the current CC graph.

You can also use about:memory I order to see zombie compartments.

CCDump extension can be used to search within the object graph and execute queries to get the information you need.

You can download from AMO, get the latest build, or clone the source code (BSD License).


After you install the extension, open: about:ccdump

You should see something as follows:

You mostly want to start by clicking on Run CC Analysis button in the Home tab. After you do it, Firefox cycle collector runs three times to clean up garbage and consequently once, with a listener, to collect entire CC graph of objects in the memory. The result object graph is immediately displayed as a table where each entry represents an object.

Every object has a context menu, just click the black triangle next to the green object label. There are three ways how to query the graph.

  • Show Details - see detailed information about the object
  • Show Roots - get roots that keep this object in the memory
  • Show Graph - get all objects that are directly or indirectly related to the object (the result is displayed as an expandable tree).

Show Graph allows to dramatically reduce the object graph to see only related objects and search further only in the sub-graph result.

You can also search the graph. Use a search box located at the top right corner. Note that if there is a string in the box the search runs automatically just after analysis (I am typically keeping nsDocument text in the box).

There are some options:

  • Find Zombie Documents - search for objects with nsDocument string in the name (i.e. for zombie content documents)
  • Find Zombie HTTP Elements - search for objects with http string in the name (i.e. for zombie content nodes)
  • Clear Search Results - trash the current search results and show the original table with entire graph.
  • Case Sensitive - case sensitive search
  • Use Regular Expression - you can also use regular expression to search the graph

The next screenshot shows object detail view:

  • address unique hexadecimal address of the object. Always clickable thorough the UI
  • refcount number of referents
  • gcmarked if false CC is OK with freeing the object
  • root if true the object is a root
  • edges array of objects referenced by this object
  • owners array of parent objects referencing this object

Where edges and owners represent relations in the graph.

Any feedback is welcome!

What could be yet improved in the UI?
What other queries could be made to the graph?
What other information in the CC graph would help to find and fix a memory leak?

Usage Scenario

My typical scenario when hunting down zombie compartments looks briefly as follows:

  1. Run the browser, reproduce a memory leak
  2. Open about:ccdump
  3. Click Run CC Analysis to get the current object graph
  4. Search for nsDocument to see a zombie document object
  5. Show Graph for the zombie document
  6. Search within the result graph for objects that keep it alive

The challenge is usually successful identification of an object in the graph and matching it with the corresponding object in the source code. Having more identity information would certainly help. Anyway, this problem should be dramatically reduced as soon as Bug 722749 i fixed - provide information about where JS object was allocated (source URL & line number).


Related resources you might find useful:

Rss Commenti


  1. Jan and Olli you are my heroes!

    Long live Firebug, quickly die zombie compartments it creates!

    FWIW I am one of those whom Mozilla thinks is abnormal in that I have quite a few extensions. Here on my home computer I don't need Firebug quite so much but being a webdev I'd become familiar with having it available. At work I need it 100% of the time. Anyway I recently disabled and uninstalled Firebug and all it's companion extensions. The difference in the browsing experience between Firebug enabled and uninstalled is like night and day.

    I really hope I can use your CCDump tool to help fight Firebug zombies.

    Congrats again!

    #1 pd
  2. > FWIW I am one of those whom Mozilla thinks
    > is abnormal...
    Yeah, I know about your comments around the web and dev tools 😉

    > I really hope I can use your CCDump tool to
    > help fight Firebug zombies.
    That would be great! I think that having bug 722749 fixed is yet important since it'll make the whole process easier.


    #2 Honza
  3. This looks great, been waiting for this a long time. I'll definitely be checking it out

    #3 Carl
  4. If you have FF13 you can use about:compartments instead of about:memory to find zombie compartments. It's much easier to use!

    #4 njn
  5. Thanks for the info! I just used about:ccdump to submit a bug for an zombie compartment. =)

    #5 geeknik
  6. @njn: I didn't know about this one, thanks for the tip!

    @geenik: great, that sounds like a music to my ears!


    #6 Honza
  7. Awesome work Honza!

    #7 Mike Ratcliffe
  8. #8 asdf
  9. @asdf: thanks for the tip! CCDump could indeed use similar "visual compression" technique and perhaps shrink the entire graph down to e.g. compartments or XUL/IFrames scopes and show only relations among them.


    #9 Honza
  10. Another thing you might find useful is the paper "Context-Sensitive Program Analysis as Database Queries":

    They use datalog (a simplified prolog) queries and BDDs to transform the source code of a program into a rule database and issue simple pattern matching queries against it to implement complex compiler transformations. The use of prolog makes many interesting transformations trivial to write.

    I think the use of a query language like prolog with tons of builtin useful predicates will make heap debugging much easier in a similar way.

    #10 asdf
  11. [...] ↑ Back to Top HomeAbout Us [...]

    #11 Feet Problems – 9 Tips for Feet Problems
  12. [...] Hunting Zombie Memory Leaks in Firefox | Software is hardFeb 27, 2012 … Thanks to Olli Pettay who implemented a new API (introduced in Firefox 13, current Nightly) that allows to dynamically analyze the CC object … [...]

    #12 Foxilla cc | Haloswat

Sorry, the comment form is closed at this time.