Closed Bug 640452 (mlk-fx5+) Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: n.nethercote, Unassigned)

Details

(Keywords: memory-leak, meta)

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.
Keywords: footprint, meta
Summary: [meta] leaks and quasi-leaks for Firefox 5.0 → [meta] leaks and quasi-leaks for Firefox 5
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.
Depends on: 634449
Depends on: 616850
Keywords: footprint → mlk
Alias: mlk-fx5
Depends on: 639515
Depends on: 642902
Depends on: 497808
Depends on: 643297
Depends on: 643300
Depends on: 642472
Depends on: 643177
Depends on: 644070
Depends on: 644073
Depends on: 644457
Depends on: 643940
Depends on: 635620
Depends on: 637782
Depends on: 644508
Depends on: 644876
Depends on: 645633
Depends on: 645277
Depends on: 635087
Depends on: 635552
Depends on: 637449
Depends on: 642306
Depends on: 607601
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+
Depends on: 650649
Depends on: 651101
Depends on: 646575
Depends on: 649334
Depends on: 651080
Depends on: 650350
Depends on: 651695
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.
Depends on: 640923
(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.
I forgot that bug 640923 was already made a dependent bug. Sorry for the spam. :P
Depends on: 653817
Depends on: 634895
Depends on: 654106
Depends on: 654399
Depends on: 654028
Depends on: 655227
Depends on: 655435
Depends on: 656120
Depends on: 656991
Depends on: 657349
Depends on: 654820
Depends on: 657658
Depends on: 653970
Depends on: 573688
No longer depends on: 634156
Depends on: 657232
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 ?
(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.
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
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Depends on: 643177
No longer depends on: 643177
You need to log in before you can comment on or make changes to this bug.