Memory Leaks
Jan Honza Odvarko
http://code.google.com/p/fbug/issues/detail?id=3312
The test page is online here:
http://getfirebug.com/tests/issues/3312/issue3312.html
... but you need to to install it (there are two files attached to the
bug report) on a local server - the memory consumption is visible much
better (at least on my machine, Firefox 4, Win Vista)
---
Here is my scenario:
1) Start Firefox (memory consumption 30-35MB)
2) Load the page (still about 30-35MB)
3) Refresh the page (F5) about 20-30 times till the memory consumption
goes to about 100MB
4) Wait, memory drops to about 60MB
5) Repeat #3 about 5-10 times
6) In the end, even after giving some time to GC for execution, the
memory consumption can settle on 100MB
Could anybody please try to reproduce that?
(I am using win task-manager to watch how much memory is consumed by
firefox process).
---
I am seeing this *without* Firebug installed (it's getting worst with
Firebug) on clean profile (no extensions).
Could anybody verify? (I can imagine that this could be hard to
reproduce)
I have also used about:memory, but this page gives different numbers
(smaller, but also growing).
Any tips on how to effectively look for memory leaks (in an extension)
is a blessing.
Honza
Pavol Mišík
> Any tips on how to effectively look for memory leaks (in an extension)
> is a blessing.
This page can help you
https://wiki.mozilla.org/Performance:Leak_Tools
I do a binary extension for Tb (no javascript) but I always build debug
version to Tb with enabled Trace-malloc to see if my extension leaks
memory allocated by exported function from xpcom.dll like ns_alloc.
Because I have to link with runtime statically I also use Visual Leak
Detector(http://vld.codeplex.com) to identify leaks that are allocated
by linked runtime on a Tb heap.
If you look for JavaScript leaks probably section *JavaScript heap dump*
can help you.
pm-
Jan Honza Odvarko
> On 4/18/2011 4:15 PM, Jan Honza Odvarko wrote:
>
> > Any tips on how to effectively look for memory leaks (in an extension)
> > is a blessing.
>
>
> I do a binary extension for Tb (no javascript) but I always build debug
> version to Tb with enabled Trace-malloc to see if my extension leaks
> memory allocated by exported function from xpcom.dll like ns_alloc.
> Because I have to link with runtime statically I also use Visual Leak
> Detector(http://vld.codeplex.com) to identify leaks that are allocated
> by linked runtime on a Tb heap.
>
> If you look for JavaScript leaks probably section *JavaScript heap dump*
> can help you.
Thanks for tips, yes only JavaScript memory leaks are interesting in
this case
Since entire Firebug is implemented purely in JS.
Honza
>
> pm-
Robert O'Callahan
window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).garbageCollect(Components.classes["@
mozilla.org/cycle-collector-logger;1
"].createInstance(Components.interfaces.nsICycleCollectorListener))
That gives you a heap dump in a file "cc-edges-NNN.log" in whatever
Firefox's current working directory is. The dump is in an obvious format.
Works in any build but gives you the best information in a debug build
(named JS edges).
Periodically creating heap dumps and then comparing the counts of different
kinds of objects should help you. You can also use the dumps to figure out
who's holding onto what.
Also, please file a Bugzilla bug given it's not Firebug-only.
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Zack Weinberg
> 1) Start Firefox (memory consumption 30-35MB)
> 2) Load the page (still about 30-35MB)
> 3) Refresh the page (F5) about 20-30 times till the memory consumption
> goes to about 100MB
> 4) Wait, memory drops to about 60MB
> 5) Repeat #3 about 5-10 times
> 6) In the end, even after giving some time to GC for execution, the
> memory consumption can settle on 100MB
This sounds exactly like a problem I'm seeing. Please cc: me on any
Firefox bugs you file for this issue.
zw
Nicholas Nethercote
>>
>> 6) In the end, even after giving some time to GC for execution, the
>> memory consumption can settle on 100MB
>
> This sounds exactly like a problem I'm seeing. Please cc: me on any Firefox
> bugs you file for this issue.
This sounds exactly like a problem that numerous people are seeing.
https://bugzilla.mozilla.org/show_bug.cgi?id=mlk-fx5%2B is tracking
them.
Nick