677949 - Need a way to find GC roots

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Steve Fink [:sfink] [:s:]]

When tracking down a "zombie compartment" bug, I found it very helpful to dump out the GC roots for a compartment. We should just have a debug call to do exactly that.

In fact, I don't see why this couldn't be made available via Components.utils as a pure-JS operation. Then you could do hunt zombies in the chrome Web Console.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Implement Components.utils.findRoots

WIP patch that adds a findRoots call which takes either the codebase of a compartment or the hex address (for distinguishing multiple [System Principal] compartments.) It returns an array of the named GC roots for the compartment.

This is early work that I'm putting on the shelf for now. It does not yet give the names of the roots (which are available in DEBUG builds for many of them.) A number of the roots don't have a toString so you can't tell much about what they are. I intend to add descriptive containers for each one instead of just returning the raw values. This should also return things rooted by cross-compartment wrappers and other (?) holders.

I'm putting this here for now because I think it's useful in its current form.

Comment 2

[Steve Fink [:sfink] [:s:]]

Attachment: Implement Components.utils.findRoots

This is still a mess, probably a bigger mess, but it's giving me useful information. In addition to the named root scanning, which is still there, this now also scans the entire JS heap and records every object in the compartment. I don't really want it to do this, but for zombie compartments it may not be too bad. (For example, in my current Firebug case, this reports exactly 4 objects. Which isn't bad.)

This patch also stops returning the actual values. Now they are only described by name and pointer. This is because I suspect that when you run this from the Web Console, it remembers the return value in its history and so adds additional roots. Not helpful.

Example output:

WebConsole> Components.utils.findRoots("http://www.nytimes.com/")
[{name:"global object", pointer:"0x7fffd417c028"},
{name:"nsXPCWrappedJS[nsIDOMEventListener,0x7fffd0b9e800:0x7fffd0b2eb60].mJSObj", pointer:"0x7fffd0aaee48"},
{name:"mScopeObject", pointer:"0x7fffd4175088"},
{name:"mScopeObject", pointer:"0x7fffd4175088"}]
                        
(gdb) p ((nsXPCWrappedJS*)0x7fffd0b9e800)->mJSObj
$80 = 0x7fffd0aaee48 [Object Function "fireContentLoadedEvent"] COMPARTMENT(principals=0x7fffda6b7828 "http://www.nytimes.com/")

(The gdb output is with archer-mozilla, including an uncommitted 'set print js-compartments on' from my local tree.)

So apparently a listener for a "ContentLoadedEvent" is lurking around, keeping the whole nytimes compartment alive.

Oh, wait. I lied. It was only 4 objects because I had closed the nytimes tab before it finished loading. After a full load, there are 49 objects in the compartment, and although the above nsIDOMEventListener is in the list, there are a lot of other nsIDOMEventListener objects that are not so easy to dissect. Oh well, too much is still better than too little, for now.

Comment 3

[Steve Fink [:sfink] [:s:]]

This has been subsumed by the GC heap graph dumping.