Last Comment Bug 640452 - (mlk-fx5+) [meta] leaks and quasi-leaks for Firefox 5+
(mlk-fx5+)
: [meta] leaks and quasi-leaks for Firefox 5+
Status: RESOLVED INCOMPLETE
: meta, mlk
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 22 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-09 20:12 PST by Nicholas Nethercote [:njn] (on vacation until July 11)
Modified: 2011-07-25 08:54 PDT (History)
101 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Nicholas Nethercote [:njn] (on vacation until July 11) 2011-03-09 20:12:17 PST
This is a follow-on bug from bug 632234, which was for leaks and quasi-leaks
for Firefox 4.0.  The following as-yet-unresolved bugs were carried over
from that bug:  bug 617569, bug 624186, bug 631536, bug 632012, bug 634155,
bug 634156, bug 634642, bug 635121, bug 636077, bug 636220, bug 638238, bug
639186, bug 639626, bug 639780.
Comment 1 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-03-09 20:28:03 PST
Note also bug 640457, which is similar to this one.  It's about tracking memory use reductions in Firefox 5 that aren't related to leaks.
Comment 2 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-04-12 18:42:16 PDT
Now that we have even shorter release cycles than the originally planned 3 month ones, I've changed this to be about Firefox 5 and on.  If this bug gets too unwieldy I'll close it out and start a new one.
Comment 3 MOW 2011-04-22 16:50:31 PDT
I'd like to request adding bug 640923 to this bug.

It's not a leak per se, but a result of delayed garbage collection, which doesn't get executed at all when there is no user interaction with the browser, e.g. when the browser window sits in the background or the machine is left unused, so the browser slowly eats up all memory and swap, which I think is enough for inclusion here.

Reloading about:memory reliably triggers garbage collection, other reloads apparently too, while just switching tabs and windows and scrolling in them is obviously not enough. (However, the value that js/gc-heap drops to after garbage collection continually rises over time. After 4 days of running, FF4 only drops down to 113,246,208 after gc compared to 69,206,016 a few hours after a fresh start. Maximum from the reload of about:memory triggering the gc itself was 385,875,968, which might be less than the actual peak because about:memory only displays after the gc is completed, which could take more than 20 minutes.)

One could also question what the browser is doing there in the background when there isn't even apparent activity (no flash active, animated images loop only once, most active content disabled by NoScript) that continually produces that much garbage needing to be collected?

Can that bug be added as is, or should I open a new one with a more fitting title ("Delayed garbage collection is delayed" or something)?

Similar behavior had already been fixed once in bug 468840, but apparently it's back.
Comment 4 Shane Bundy 2011-04-29 03:58:59 PDT
(In reply to comment #3)
> I'd like to request adding bug 640923 to this bug.
> 
> It's not a leak per se, but a result of delayed garbage collection, which
> doesn't get executed at all when there is no user interaction with the browser,
> e.g. when the browser window sits in the background or the machine is left
> unused, so the browser slowly eats up all memory and swap, which I think is
> enough for inclusion here.
> 
> Reloading about:memory reliably triggers garbage collection, other reloads
> apparently too, while just switching tabs and windows and scrolling in them is
> obviously not enough. (However, the value that js/gc-heap drops to after
> garbage collection continually rises over time. After 4 days of running, FF4
> only drops down to 113,246,208 after gc compared to 69,206,016 a few hours
> after a fresh start. Maximum from the reload of about:memory triggering the gc
> itself was 385,875,968, which might be less than the actual peak because
> about:memory only displays after the gc is completed, which could take more
> than 20 minutes.)
> 
> One could also question what the browser is doing there in the background when
> there isn't even apparent activity (no flash active, animated images loop only
> once, most active content disabled by NoScript) that continually produces that
> much garbage needing to be collected?
> 
> Can that bug be added as is, or should I open a new one with a more fitting
> title ("Delayed garbage collection is delayed" or something)?

That sounds like a bug that would make sense to add to this one as it is a major issue for those users with low memory machines. I do agree the title needs to be more of a fitting one but it's a fitting bug nonetheless.
Comment 5 Shane Bundy 2011-04-29 04:01:26 PDT
I forgot that bug 640923 was already made a dependent bug. Sorry for the spam. :P
Comment 6 John Hesling [:John99] 2011-05-24 09:54:45 PDT
This is probably rather a naive question to ask. Presumably additional instances of plugin container increase memory usage. Probably it is assumed this will be negated by disabling plugins, there is however a bug 633427

>Cookies will start an instance of plugin-container 
>for almost all of the plugins installed on the system, 
>regardless of enable/disable state for each one.

Would this mean that it is necessary to do more than just disable plugins when running tests on memory, or are all reporters and testers going to immediately notice if bug 633427 is involved ?
Comment 7 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-05-24 17:37:49 PDT
(In reply to comment #6)
> This is probably rather a naive question to ask. Presumably additional
> instances of plugin container increase memory usage. Probably it is assumed
> this will be negated by disabling plugins, there is however a bug 633427
> 
> >Cookies will start an instance of plugin-container 
> >for almost all of the plugins installed on the system, 
> >regardless of enable/disable state for each one.
> 
> Would this mean that it is necessary to do more than just disable plugins
> when running tests on memory, or are all reporters and testers going to
> immediately notice if bug 633427 is involved ?

I don't think it's a naive question.   You omitted the word "clearing" from the start of that quote, which changes its meaning significantly.  So, basically, bug 633427 means that if you clear all cookies, multiple plugin-containers will be created, which will increase memory usage in a non-obvious way, which is undesirable.  But people don't clear their cookies very often so I don't think this will cause many problems with bug reports in practice.
Comment 8 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-05-25 21:50:25 PDT
This bug is being decommissioned in favour of the a new collection of       
per-version leak tracking bugs.  All its dependencies have been removed.    
Bug 659856, bug 659857, and bug 659858 are the replacement bugs.  Please CC yourself to the new bugs if you are interested.

Note You need to log in before you can comment on or make changes to this bug.