Better tools for memory leak analysis

[Jan Honza Odvarko]

I have spent a lot of time hunting down memory leaks in Firebug (issue still open) and it was always painful and frustrating experience. There are not many tools available that would help to make the whole work simpler.

The best way I have found so far, that helps to:
a) see that my test-case is actually leaking
b) get some information what (JS) objects are leaking

...is using about:memory and CC heap dump.

CC heap dump:

window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).
getInterface(Components.interfaces.nsIDOMWindowUtils).
garbageCollect(Components.classes["@mozilla.org/cycle-collector-logger;1"]
.createInstance(Components.interfaces.nsICycleCollectorListener))

This is quite powerful way but has two weaknesses:

1) It's hard (mostly almost impossible at least in case of Firebug) to identify the object in the log and match with an object in the code. Some more info in the log would be invaluable.

I don't know what is possible, but this could be: url and source line where the object is created or all existing properties of the object (e.g. primitive values, numbers, or just string props would be enough)

2) The process of getting the log and doing analysis is painful - you need to generate a text file, open in an editor, search in it, use further scripts for analysis, etc. (it's simple to kill several hours even with a simple scenario how to repro the problem)

There is no way how to iterate entire CC heap graph from JS. This would be huge!

It would allow dynamic creation and analysis of the heap and safe a loot of time. Ideally, this could be also used to create an automated test for memory-regression leak bugs in extensions.

Both #1 and #2 would be really useful for all extension developers who care about memory. Please, pretty please, could we get at least one of it?

Here is one related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=zombiehunter

Honza

[Andrew McCreight]

Hi,

----- Original Message -----
> I have spent a lot of time hunting down memory leaks in Firebug
> (issue still open) and it was always painful and frustrating
> experience. There are not many tools available that would help to
> make the whole work simpler.
>
> The best way I have found so far, that helps to:
> a) see that my test-case is actually leaking
> b) get some information what (JS) objects are leaking
>
> ...is using about:memory and CC heap dump.
>
> CC heap dump:
>
> window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).
> getInterface(Components.interfaces.nsIDOMWindowUtils).
> garbageCollect(Components.classes["@mozilla.org/cycle-collector-logger;1"]
> .createInstance(Components.interfaces.nsICycleCollectorListener))
>
> This is quite powerful way but has two weaknesses:
>
> 1) It's hard (mostly almost impossible at least in case of Firebug)
> to identify the object in the log and match with an object in the
> code. Some more info in the log would be invaluable.
>
> I don't know what is possible, but this could be: url and source line
> where the object is created

Luke was saying it might be possible to leverage type inference information to get something like this, but I haven't quite figured out how to get that to work. Though now that I am thinking about it, for the kind of work you are doing, is TI enabled or is it using the interpreter? I don't really know how Firebug operates.

> or all existing properties of the object
> (e.g. primitive values, numbers, or just string props would be
> enough)

I think this may be not be too difficult. I recently added a way to dump a complete JS heap, in the same way that you can currently dump a CC heap. The main problem is that there's no way right now to actually produce a log without recompiling the browser. Bug 696174 aims to fix that. It will produce a JS heap dump any time you produce a CC dump, so you get a snapshot of a single point in time.

With a GC heap dump, you get what various strings are:

05F1BC20 string blockString
05F1F7B0 string popupWarningDontShowFromMessage
05F1F7A0 string popupWarningDontShowFromLocationbar

I'm not super familiar with how this all works, but it doesn't sound impossible to display primitive values, too.

Generally, though, I think the place for this detailed information about JS objects is in the JS heap dump.

> 2) The process of getting the log and doing analysis is painful - you
> need to generate a text file, open in an editor, search in it, use
> further scripts for analysis, etc. (it's simple to kill several
> hours even with a simple scenario how to repro the problem)
>
> There is no way how to iterate entire CC heap graph from JS. This
> would be huge!
>
> It would allow dynamic creation and analysis of the heap and safe a
> loot of time. Ideally, this could be also used to create an
> automated test for memory-regression leak bugs in extensions.

So, I've been thinking a lot about this, and I agree it would be really cool to have, because people who care about looking at the Firefox cycle collector heap are more likely to be fluent in Javascript than Python, and it would be nice to do automated testing like you mention. It would also be less clunky to be able to just analyze things with a single button, instead of having to create a log, then analyze it from the command line.

But otherwise, anything you can do with a JS analyzer script should be possible to do with my existing Python scripts. I have a parsing library you can use to pull a file into a fairly easy to use graph that you can analyze. If there are additional things you'd like to be able to do from scripts, we should discuss that and I can figure out how to help you get that done.

Andrew

> Both #1 and #2 would be really useful for all extension developers
> who care about memory. Please, pretty please, could we get at least
> one of it?
>
> Here is one related bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=zombiehunter
>
> Honza

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jan Honza Odvarko]

Sounds promising, I created two bug reports:

#1) Better logging: https://bugzilla.mozilla.org/show_bug.cgi?id=722749
#2) Expose API to JS: https://bugzilla.mozilla.org/show_bug.cgi?id=722750

Honza

[Jan Honza Odvarko]