Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 640452 (mlk-fx5+)

[meta] leaks and quasi-leaks for Firefox 5+

RESOLVED INCOMPLETE

Status

()

Core
General
RESOLVED INCOMPLETE
7 years ago
6 years ago

People

(Reporter: njn, Unassigned)

Tracking

({meta, mlk})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Keywords: footprint, meta
(Reporter)

Updated

7 years ago
Summary: [meta] leaks and quasi-leaks for Firefox 5.0 → [meta] leaks and quasi-leaks for Firefox 5
(Reporter)

Updated

7 years ago
(Reporter)

Comment 1

7 years ago
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.
(Reporter)

Updated

7 years ago
Depends on: 634449
(Reporter)

Updated

7 years ago
Depends on: 616850

Updated

6 years ago
Keywords: footprint → mlk
(Reporter)

Updated

6 years ago
Alias: mlk-fx5
(Reporter)

Updated

6 years ago
Depends on: 639515
Depends on: 642902
Depends on: 497808
Depends on: 643297
Depends on: 643300

Updated

6 years ago
Depends on: 642472

Updated

6 years ago
Depends on: 643177
Depends on: 644070
Depends on: 644073

Updated

6 years ago
Depends on: 644457

Updated

6 years ago
Depends on: 643940

Updated

6 years ago
Depends on: 635620

Updated

6 years ago
Depends on: 637782

Updated

6 years ago
Depends on: 644508

Updated

6 years ago
Depends on: 644876

Updated

6 years ago
Depends on: 645633

Updated

6 years ago
Depends on: 645277
Depends on: 635087

Updated

6 years ago
Depends on: 635552
Depends on: 626539
(Reporter)

Updated

6 years ago
Depends on: 637449
(Reporter)

Updated

6 years ago
Depends on: 642306
(Reporter)

Updated

6 years ago
Depends on: 607601
(Reporter)

Comment 2

6 years ago
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.
Alias: mlk-fx5 → mlk-fx5+
Summary: [meta] leaks and quasi-leaks for Firefox 5 → [meta] leaks and quasi-leaks for Firefox 5+

Updated

6 years ago
Depends on: 650649
(Reporter)

Updated

6 years ago
Depends on: 651101
(Reporter)

Updated

6 years ago
Depends on: 646575
(Reporter)

Updated

6 years ago
Depends on: 649334

Updated

6 years ago
Depends on: 651080
(Reporter)

Updated

6 years ago
Depends on: 650350
Depends on: 651695

Comment 3

6 years ago
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.
(Reporter)

Updated

6 years ago
Depends on: 640923

Comment 4

6 years ago
(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

6 years ago
I forgot that bug 640923 was already made a dependent bug. Sorry for the spam. :P
(Reporter)

Updated

6 years ago
Depends on: 653817
(Reporter)

Updated

6 years ago
Depends on: 634895
Depends on: 654106

Updated

6 years ago
Depends on: 654399

Updated

6 years ago
Depends on: 654028

Updated

6 years ago
Depends on: 655227
Depends on: 655435
(Reporter)

Updated

6 years ago
Depends on: 656120

Updated

6 years ago
Depends on: 656991
(Reporter)

Updated

6 years ago
Depends on: 657349
(Reporter)

Updated

6 years ago
Depends on: 654820
(Reporter)

Updated

6 years ago
Depends on: 657658
(Reporter)

Updated

6 years ago
Depends on: 653970
(Reporter)

Updated

6 years ago
Depends on: 573688
(Reporter)

Updated

6 years ago
No longer depends on: 634156

Updated

6 years ago
Depends on: 657232
(Reporter)

Updated

6 years ago
Depends on: 659220
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 ?
(Reporter)

Comment 7

6 years ago
(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.
(Reporter)

Comment 8

6 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Updated

6 years ago
(Reporter)

Comment 9

6 years ago
For history's sake, here is the list of bugs this bug depended on just before it 
was decommissioned:

unresolved: 
bug 497808, bug 573688, bug 616850, bug 617569, bug 624186, bug 631536, 
bug 632012, bug 634449, bug 634895, bug 635121, bug 635620, bug 636077,
bug 636220, bug 637449, bug 637782, bug 638238, bug 639186, bug 639515, 
bug 639780, bug 640923, bug 642472, bug 643177, bug 643940, bug 644073,
bug 644876, bug 645633, bug 646575, bug 650350, bug 650649, bug 651695,
bug 653817, bug 653970, bug 654028, bug 654820, bug 655227, bug 656120,
bug 657658, bug 659220

resolved: 
bug 607601, bug 626539, bug 634155, bug 634642, bug 635087, bug 635552, 
bug 639626, bug 642306, bug 642902, bug 643297, bug 643300, bug 644070, 
bug 644457, bug 644508, bug 645277, bug 649334, bug 651080, bug 651101,
bug 654106, bug 654399, bug 655435, bug 656991, bug 657232, bug 657349
(Reporter)

Updated

6 years ago
Depends on: 643177
(Reporter)

Updated

6 years ago
No longer depends on: 643177
You need to log in before you can comment on or make changes to this bug.