640923 - Major memory leak - the longer firefox is left open, the more memory it uses

Status: RESOLVED DUPLICATE of bug 659856

(Firefox :: General, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110310 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110310 Firefox/4.0b13pre

Major memory leak - the longer firefox is left open, the more memory it uses 

Reproducible: Always

Steps to Reproduce:
1.open several sites
2.let firfox open, no any other actions
3.15 or 30 minutes later, in the windowns's task manager, could see the larger and larger memeory ocuppied when time goes by.
Actual Results:  
Major memory leak - the longer firefox is left open, the more memory it uses 

Expected Results:  
no memory leak.

Comment 1

[Matthias Versen [:Matti]]

Such a bug report is only usewfull with exact steps to reproduce.

>1.open several sites

URLs
>3.15 or 30 minutes later, in the windowns's task manager, could see the larger
and larger memeory ocuppied when time goes by.

Example memory values ?

Do you already tried it without addons ?

Comment 2

[Asa Dotzler [:asa]]

without specifics, this is not a blocker. re-nominate if you can demonstrate how to reproduce.

Comment 3

[Steven Veldkamp]

I've a lot of plugins and add-ons, and experienced a serious memory leak when watching long YouTube videos. But it's not Firefox, because it doesn't happen in Safe Mode.

Comment 4

[Matthias Versen [:Matti]]

It could be still Firefox if it doesn't happen in the safemode.
The safemode does more than disabling the addons. Test witg manual disabled extensions to be sure.

Comment 5

[[e-mail]]

Yes, I tried it without any addons and without any plugins.

firstly, open two tabs: www.sina.com.cn and finance.sina.com.cn/stock.
then, when these two tabs opened completely, the memory used is 110M.
Next, I left firefox opened without any touch.
25 minutes later, the memory used is 180M.

my computer's specificatin: CPU intel Q9550, RAM 4G, Geforce GTS 250, win7 professional 32bit.

Comment 6

[Thomas]

VERY bad memory leak Firefox 4 RC1.

To produce:
1. Open 4 tabs going to random sites
2. Leave Firefox open for 2-3 hours, my particular instance was open for about 12 hours
3. Check task manager: Right now I am using 15% cpu consistently, the memory is it 525,744k - consistently raising up. It's actually at 531,950k already while typing this - about 15 seconds
4. Closing Firefox and reopening results in perfect run. Firefox is using more memory then Photoshop CS5, Visual Studio 2010, Steam, Explorer, MSSQL Management Studio - it's using the most memory in all apps open.

http://dl.dropbox.com/u/13174267/ff4.png

Comment 7

[Thomas]

Attachment: Showing memory usage

Comment 8

[Thomas]

I should also note:
 - The browser gets noticeably laggy 
 - Occurs a lot, I'm a web developer so usually have a lot of tabs open
 - Have disabled all the plugins and themes, still same thing.
 - As I am typing this, my text is lagging behind from using a lot of CPU usage+memory. 
 - The memory will random spike up, and then drop back down. 
 - It's CONSTANTLY changing. No other application running does this, it's increasing/decreasing in memory usage every 1 second
 - The CPU usage is random, but never exceeds 15% for some reason
 - Very easy to reproduce. Lets get this fixed!!

Comment 9

[Peter Steinbrueck]

about:memory open in one tab and refreshing it from time to time seems to help a little. 
With every refresh of about:memory mem usage drops back to the level when I had opened about:memory. 
(NT6.1 x64, FF4.0 in safe mode, app. 20 tabs open)

Comment 10

[MOW]

Seeing a similar issue.
When actively browsing, memory usage goes up and down.
Current values, with a lot of tabs in 2 windows:

Memory mapped:497,025,024
Memory in use:477,527,218
win32/workingset 340,062,208
js/gc-heap 65,011,712

But when Firefox is left overnight, memory usage increases until virtual memory is exhausted. In that case, FF gets so sluggish that it can't even exit gracefully (warning about sessionstore script using too much time, not possible to click).

I just had it running unattended for about 1 hour, and it grew about 100MB, which were freed when I opened about:memory.

Wild guess: Garbage collection only gets triggered during user interaction?
Is about:memory a trigger for garbage collection?

But it still would be interesting to know what it is that Firefox is doing when I'm not there. GIF animations are set to loop once, there is no flash stuff open, and most JS stuff disabled by noscript. I don't even see animated favicons. So I'm left to wonder what is causing this annoyance.

Comment 11

[MOW]

Okay, this time I came back early enough so Firefox wasn't totally impossible to use. I was away for 3 1/2 hours, and Task Manager showed a total memory use of 842M, with Firefox using 397M+656M virtual.
Without doing anything else in Firefox, I switched to the tab where I had about:memory open and reloaded. This took a long time and brought up a warning about script: chrome://global/content/aboutMemory.js:97 being unresponsive, when I clicked to continue it showed 410M workingset with 200M used in js/gc-heap. (And if Firefox actually would save the displayed page instead of only saving an empty template I could give you the complete figures.)

Then I noticed a sharp memory drop in Task Manager to a total of 640M, with Firefox using 258M+453M virtual. So the about:memory script triggered a garbage collection. I reloaded the page again, which went considerably faster. The drop in the working set was apparently due to js/gc-heap dropping to only 62M.

Now, 1 1/2 hours later after some browsing, Firefox was back at 402M+550M.
Reloading about:memory again, I got

Overview
Memory mapped: 602,931,200
Memory in use: 529,058,126
Other Information
Description
            Value
malloc/allocated529,062,182
malloc/mapped602,931,200
malloc/committed538,976,256
malloc/dirty3,211,264
win32/privatebytes1,231,588
win32/workingset421,470,208
js/gc-heap62,914,560
js/string-data42,826,364
js/mjit-code0
storage/sqlite/pagecache19,817,312
storage/sqlite/other1,216,104
gfx/d2d/surfacecache0
gfx/d2d/surfacevram0
gfx/surface/win32 4,498,771
images/chrome/used/raw0
images/chrome/used/uncompressed193,160
images/chrome/unused/raw0
images/chrome/unused/uncompressed0
images/content/used/raw14,485,246
images/content/used/uncompressed6,897,880
images/content/unused/raw0
images/content/unused/uncompressed0
layout/all48,262,239
layout/bidi228
gfx/surface/image12,144

(cut&paste of this sucks!)
which apparently triggered another gc, because in Task manager FF's memory usage went down to 333M+470M, after another reload the current values are

Overview
Memory mapped: 513,802,240
Memory in use: 426,651,020
Other Information
malloc/allocated426,646,884
malloc/mapped513,802,240
malloc/committed445,796,352
malloc/dirty2,707,456
win32/privatebytes1,231,588
win32/workingset329,043,968
js/gc-heap62,914,560
js/string-data5,537,908
js/mjit-code0
storage/sqlite/pagecache19,817,312
storage/sqlite/other1,216,104
gfx/d2d/surfacecache0
gfx/d2d/surfacevram0
gfx/surface/win32 4,496,975
images/chrome/used/raw0
images/chrome/used/uncompressed193,160
images/chrome/unused/raw0
images/chrome/unused/uncompressed0
images/content/used/raw14,484,517
images/content/used/uncompressed6,896,084
images/content/unused/raw0
images/content/unused/uncompressed0
layout/all48,257,051
layout/bidi228
gfx/surface/image12,144

Between these two, working set dropped by 55M more than the 35M difference in js/string-data. Also, the working set is still 70M bigger than the 258M after the first trigger of garbage collection. Does anyone know what's using the missing 125M not showing up in the breakdown?

tl;dr: Firefox should run garbage colletion even if it is idle with no user interaction to avoid growing to the system's limits.

Comment 12

[Peter Steinbrueck]

Triggering gc by refreshing about:memory isn't sufficient. Memory still grows after new tabs have been opened and closed. It looks like after closing tabs the associated memory gets "lost".

Comment 13

[Boris Zbarsky [:bzbarsky]]

MOW, please open a new bug on your issue?

Comment 14

[Hugh Nougher [:Hughman]]

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Observations of CPU and memory usage are similar to those above, though over a much longer period of time (few days). I see memory/CPU spikes together at regular intervals of around 15-20 seconds which get larger as the memory usage rises. If the memory gets upto 1GB then CPU spikes can be a few seconds long along with extra 300MB mem spike. I suspect (with no knowledge of inner workings) that this spike is related to a GC run where there is an excessive number of items in it waiting for cleanup that never do get cleaned.

Could I suggest to the above testers that they retest with firefox 4.0.1 which has a number of memory fixes especially over the beta and RC versions? Best if you can attach the user-agent string found in about:support with any results.

Comment 15

[Nicholas Nethercote [inactive]]

MOW, I've marked this as blocking bug 640452 as you requested in bug 640452 comment 3.  But as Boris suggested in comment 13, you should open a new bug.  We have a number of leak bugs where multiple people have piled on with vaguely similar symptoms and it becomes very confusing.  Also, your description is very vague.  Are there particular sites that you've noticed make the problem worse?  If there are, please list them.  If not, the chance of the problem being fixed as a result of your bug report is close to nil.

Also, you didn't say if you are running any add-ons which is always the first question for anyone reporting a leak.  Eg. see bug 607601.

Comment 16

[SineSwiper]

Will somebody confirm and fix this bug?  We already have 10 votes on it already.  It's confirmed!

I'm willing to provide all of the specifics to help out.  I'm currently running about 700 freaking MB of memory on this thing, and I have to reload Firefox every day.  When it's like this, it likes to pause my mouse or keyboard every 10 seconds or so.  Here are my specs:

Windows 7 (64-bit)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

The about:memory screen gives me the big usage here:

Memory mapped: 747,634,688
Memory in use: 584,344,000

malloc/allocated   584,347,144
malloc/mapped      747,634,688
malloc/committed   616,284,160
malloc/dirty         3,272,704
win32/privatebytes 703,954,944
win32/workingset   753,115,136
js/gc-heap         145,752,064
js/string-data       7,194,516
js/mjit-code         2,002,198
storage/sqlite/pagecache 52,615,504

Everything else is pretty small.  This is basically making Firefox close to unusable, and I'm shocked that this thing even made it to production.  Please don't let this bug last for 6 months.  This is a "must fix in a week" bug, and should be marked as such somewhere in the ticket.

Comment 17

[Yakove]

For me in latests nightlies this bug looks like fixed, no more leaks

Comment 18

[Frank Nestel]

Well, from monitoring bugzilla seems like quite a few bugs, which could have contributed to this thing (a behaviour rather than one isolated bug), have been fixed. 

Not really familiar with organistion: Do we have to look for a FF5 nightly, or is there a FF4.0X branch including those fixes for the case of a zero day? I mean there seems to be plenty of it over here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Comment 19

[Nicholas Nethercote [inactive]]

SineSwiper, I appreciate your frustration but it's not that simple.

First, there are multiple possible leaks that are causing your problems.  See bug 640452, which is tracking all the bug reports that have been file about memory leaks in the last few months.  It's probable that that list includes lots of cuplicateds, and it's possible that the leak you are seeing has already been fixed.  Firefox 5 will be out in about 6 weeks.

Second, as I said in comment 15, this report is hard to act on.  The steps to reproduce are vague, the memory metrics being used are inconsistent, and multiple people have piled on.  I'm working on improving about:memory, see http://blog.mozilla.com/nnethercote/2011/05/02/a-better-aboutmemory-stage-1/ and http://blog.mozilla.com/nnethercote/2011/05/12/a-better-aboutmemory-stage-1-5/.  Those changes will make it much easier for users to provide more information, and more consistent information, increasing the likelihood of fixes happening.  These changes will be in Firefox 6, which will be out in about 12 weeks.

So there are numerous people working to make things better.  If you want to help further, here's what you can do:

- Install a Nightly version of Firefox from http://nightly.mozilla.org/.

- See if you still have problems with it.

- If you do, try to make the steps to reproduce as specific as possible.  If you can narrow it down to a single website, that will make it much easier for someone to act on it.  It's almost impossible to act on a report like "I browse for a few hours and memory usage grows really high".

- If you can do that, file a new bug, and include about:memory output.  With the changes I've made it cut+pastes much more nicely now.

- Oh, and do you have add-ons installed?  If so, please disable them.

I hope this clarifies things.  Please ask if you have questions.  Thanks.

Comment 20

[Nicholas Nethercote [inactive]]

(In reply to comment #18)
> 
> Not really familiar with organistion: Do we have to look for a FF5 nightly,
> or is there a FF4.0X branch including those fixes for the case of a zero
> day? I mean there seems to be plenty of it over here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Or http://nightly.mozilla.org, which is is easier to use.

There's no 4.0.x branch including fixes like these.  If a zero-day occurs and a "chemspill" release needs to be pushed out quickly, it'll just be the last stable release plus the fix for the zero-day.

Comment 21

[SineSwiper]

If this is already fixed in Firefox 5, it should have been backported to Firefox 4 immediately.  Firefox 4 is the stable version.  Bugs marked critical should have their **** fixed pronto and backported to the stable version.

Now, I just spent 8 hours testing this bug.  (Granted, most of it was just letting it sit, but it's still a good 2 hours of compiling the information.)  Guess what I found.  It leaks with plug-ins.  It leaks without plug-ins.  It leaks without JS.  It leaks in safe mode.  It leaks on the goddamn "about:memory" page only!

So, what's causing it?  Well, I realized that even in safe mode, the thing is loading RSS feeds on timers.  And every time it does that, the memory goes up about 10MB.  RSS feeds!  And it doesn't matter which one.  It's going to several different sites.  And this isn't a leak; it's a goddamn firehose!  Having 30MB leak every hour is going to reach a gigabyte in a little over 24 hours!  Just because it's sitting there.

Now, do you know who uses RSS feeds?  EVERYBODY!  Do you know who could have tested this bug?  ANYBODY!  Including developers.  Don't give me this "Oh, we can't reproduce the situation" or "I don't have enough information to test this".  Any moron with a Windows 7 PC who uses their Firefox as their standard browser could have tested.  Including developers.  Including QA people.  Including anybody who has any active part behind-the-scenes with Firefox.

Maybe you should have tested this out before releasing it to the FOUR HUNDRED MILLION people who use Firefox!  Maybe you should have fixed it before it get out on the news!  Oh, wait, too late: http://www.google.com/search?q=Firefox+memory+leak&um=1&tbm=nws

And I don't give a **** about Firefox 5.  Firefox 5 is not production.  Nobody uses Firefox 5.  When I go to mozilla.com, it says I have the same version that it's offering.  Your FOUR HUNDRED MILLION users are using Firefox 4.0.1.

I don't give a **** about Firefox 5 getting released in 6 weeks.  This bug was announced 8 weeks ago, where it produced 8 comments, 10 votes, has sat here for a few months.  Given that this bug was opened before the March 22 release date for 4.0.1, that means it's been an issue since Firefox 4, probably even earlier into the betas.

Memory usage is one of the most important issues for browsers in the face of competition like Chrome.  And you guys **** it up.  Congratulations!

I don't know how much shouting and cussing I have to do to get you lazy **** to do anything, but if this was a corporation releasing some bloated PoS like this, either somebody's ass would be on a flamethrower to fix it, or somebody would get fired.  You guys are about the laziest development team I've ever had the pleasure of bitching at.  You have open bugs that are 13 years old.  You have open bugs with over 300 votes.  (Hell, the oldest bug (bug 915) is about inheritance of alignment attributes from columns.  How the hell do you pass an Acid test when you still have a bug like that?)

Confirm it.  Find it.  Fix it.  Backport it.  Soak it.  Release it.  Now!

Comment 22

[SineSwiper]

Attachment: Test results of RSS memory leak

Oh, and here's your test results.  Enjoy!

Comment 23

[Justin Dolske [:Dolske]]

SineSwiper: Have you tried therapy and/or medication for you anger-management issues?

Comment 24

[Nicholas Nethercote [inactive]]

Dolske: let's try to keep this on topic.

SineSwiper: you know, you and I are on the same side.  We'd both like to see all of Firefox's memory leaks fixed.  You obviously care enough that you took the time to compile the data in the attachment, so thanks for that.  But insults won't get you anywhere.  I'm prepared to spin off a new bug and work with you to try to fix things, if you agree to be civil in the new bug.  How's that sound?

This sounds similar to bug 650649, BTW.  Memory usage can go up legitimately even if the user isn't doing anything, because Firefox might be doing things in the background, like updating its phishing blacklists.

Comment 25

[SineSwiper]

And what the hell is that going to do?  Bug 650649 has been opened since last month, and it's not been fixed.  I've provided you with detailed Process Explorer graphs of the memory usage for each test, and a complete all:5 log of Firefox during test #6.  The only thing I forgot was the memory increase time points of graph #6, which are:

6:47:19 PM
6:56:10 PM
7:05:31 PM
8:05:14 PM
(+/- 20 secs)

What more do you need from me?  Everything is on highest debug, with the smallest case example that still works.  Do I need to buy the Windows 7 PC for you, too?

I get aggravated with you guys because of both the glacial pace that critical things get fixed, and the unrealistic expectations that you want from your users to get it fixed.  I provide enough data to pinpoint the problem, and you're supposed to try it out with the conditions and say "Yep, we can duplicate the problem".  And that's it.  That's how it's supposed to work.  From there, you can put in whatever debug code you need to figure out where the problem lies and fix it.

Here's how it actually works here: We (the users) all bitch on the bug report and provide enough data until somebody (a user) provides a patch, or somebody (a user) creates a plugin (with 10K downloads/week as was the case with bug 61098) to fix the problem.  From there, more bitching happens before eventually, ten years later, the bug has reached over 300 comments and over 100 votes, and an actual Firefox developer finally installs a patch and makes it live.

Not saying that this bug will go ten years.  (I really hope not.)  But, the more severe the problem, the fast it needs to be fixed.  This one is extremely bad, and it's horrible PR.  You want to know why Chrome is taking a chunk out of Firefox's market share.  This.  This bug is it.

Comment 26

[[e-mail]]

Glad to see this bug has gained your attention. it still lies in fx5.xx, fx6.xx according to my test.

wish it be fixed a.s.a.p.

Comment 27

[Frank Nestel]

Well, FF5b2 is really doing way better in my environment. This is great! I'll abandon FF4 now for me, it never was "stable" in my world.

The point that has to worry us for the future, these problems were there in all FF4 betas and quite a few people, including me, tried to make this an issue. However plenty got stuck in the "disable all addons", "use a new profile" and "why do you use that many tabs" arguments. I mean, the problem didn't go away, but also what is FF4 good for, without my profile, without my tabs and without my addons? I am really looking forward to a user friendly memory analysis machinery. Isn't there any hope to get this into 5 instead of 6? I mean Chrome is there, Microsoft is back and Opera is never gone (I am a Safari hater BTW), quality should help Firefox to stay. 

Looking forward to FF5 final!

Comment 28

[Nicholas Nethercote [inactive]]

(In reply to comment #27)
> Well, FF5b2 is really doing way better in my environment. This is great!

Good to hear!

> The point that has to worry us for the future, these problems were there in
> all FF4 betas and quite a few people, including me, tried to make this an
> issue. However plenty got stuck in the "disable all addons", "use a new
> profile" and "why do you use that many tabs" arguments. I mean, the problem
> didn't go away, but also what is FF4 good for, without my profile, without
> my tabs and without my addons?

I can sympathize.  The problem is that bugs can be really hard to reproduce because there are so many sources of noise -- add-ons, profiles, settings, etc.  That's why we usually ask people to turn off add-ons and test with fresh profiles, because it removes a lot of that noise and helps with reproducing and diagnosing.  (The "why do you use that many tabs" argument is pretty weak, though!)  Sometimes the problem is with the add-ons or the profile, of course, but often it's not.

And leaks are even worse because the symptoms can be vague, and it's very difficult to tell if two different leak reports are caused by the same leak or different leaks.  And it can also be difficult to tell if a rise in memory usage is actually a leak or something non-obvious but legitimate.

Plenty of memory work was done for FF4 (see bug 598466 and bug 615199 for some examples) but some things were missed.  It wasn't helped by FF4 being almost 6 months late;  at some point the decision became "is this clearly better than 3.6 for the vast majority of users, despite its flaws" and the answer was deemed to be "yes".  You may disagree, but that's how it happened.

Not that this excuses the problems in FF4, but maybe it makes some things clearer.  Now that we have a 6 week release cycle it should allow for more gradual improvement, and less likelihood of big regressions.  And there's lots of work being done behind the scenes to improve memory usage tracking, so I'm cautiously optimistic.

> I am really looking forward to a user
> friendly memory analysis machinery. Isn't there any hope to get this into 5
> instead of 6?

I doubt it, sorry.

Comment 29

[SineSwiper]

Well, I guess I'll just have to as direct as possible:

Can you, Nicholas, and you, Justin, try this out on a Windows 7 PC, using the same test conditions that I provided (about:memory tab only, Safe Mode, full debug), and see the same result?  This appears to be a more global issue than just 1% of the userbase.  I mean, I seriously think this is every single Windows 7 user with RSS feeds (or possibly tied to the 64-bit version).  Maybe even more than just that OS, because the other bug report (bug 650649) had MacOS users having the same problem.

Just be sure to grab a copy of Process Explorer (great tool, anyway) and set the refresh speed to 10 seconds, then capture the graph like I have.

The best way to cut down the noise is to just do it yourself and be closest to the source.  I can't provide much more information than I already have.  I can't smartly add debug code to further pinpoint the problem.  I can't compile the code, especially on a Windows machine.

And if you guys aren't Firefox developers, can you contact the guys who work on these pieces and tell THEM to test it out on a Windows 7 PC?  Whoever works on RSS feeds and is familiar with the HTTP calls.

This isn't a forum to write messages back and forth.  It's a bug report.  Bugs require testing from the people who wrote the software, not just the users.  You can't expect the answers to fall from the sky, and you can't expect the userbase to magically provide you with a patch.  I know this is OSS, but 80% of the work still comes from the select few people who actually work with the code.

Comment 30

[Nicholas Nethercote [inactive]]

(In reply to comment #29)
> 
> Can you, Nicholas, and you, Justin, try this out on a Windows 7 PC

I am a Firefox developer but I don't have a Windows 7 PC, and I don't see problems like this on my Linux or Mac machines.

> This appears to be a more global issue than just 1% of the userbase.  I mean,
> I seriously think this is every single Windows 7 user with RSS feeds (or
> possibly tied to the 64-bit version).

Why do you think that?  I'm asking that earnestly:  what evidence do you have for this statement?  I just wrote http://blog.mozilla.com/nnethercote/2011/05/24/leak-reports-triage-may-24-2011-2/ which involved going through 40 recently filed leak reports and my sense (which may be wrong) is that it's not as prevalent as you think.

> This isn't a forum to write messages back and forth.  It's a bug report. 
> Bugs require testing from the people who wrote the software, not just the
> users.  You can't expect the answers to fall from the sky, and you can't
> expect the userbase to magically provide you with a patch.  I know this is
> OSS, but 80% of the work still comes from the select few people who actually
> work with the code.

Bugzilla is definitely a forum for writing messages back and forth.  Bug reports provided by responsive users who are willing to do multiple experiments are much more likely to end up getting fixed.  You may think this is not how it should work, but that is how it does work in practice.  I also think you are underestimating how easy it is to reproduce problems.

One thing that wasn't clear in the results you've provided -- are you still testing with 4.0.1?  It would be interesting to know if you still see the problem with Firefox 5 betas (eg. see comment 28), if you are willing to try it.

Comment 31

[Justin Dolske [:Dolske]]

(In reply to comment #29)

> Can you, Nicholas, and you, Justin, try this out on a Windows 7 PC, using
> the same test conditions that I provided (about:memory tab only, Safe Mode,
> full debug), and see the same result?

Since you asked nicely...

I gave this a spin with Firefox 4.0.1 on my Windows 7 x64 box with a new profile (didn't enable logging or safe mode, though). Memory use does initially grow, but seems to stabilize after an hour or so (from ~25MB to ~75MB). The total increase seems to roughly match the storage/sqlite/pagecache increase, so this is probably just the initial Safe Browsing DB download (see bug 650649).

I'll try letting it run overnight, but using a new profile with SB disabled.

Comment 32

[Justin Dolske [:Dolske]]

Seems fine to me -- started at ~25MB, was at ~32MB this morning, and still about the same level tonight.

Comment 33

[Nicholas Nethercote [inactive]]

Justin, this is privatebytes as measured by the Task Manager?

Comment 34

[Frank Nestel]

OK, I know, it doesn't help you searching, but maybe it helps you judging importance. I'll post this, please excuse.

In my usage pattern (what is fairly stable):
- FF 3.6.16 needed two restarts a month.
- FF4.01 ran a few hours, even shorter when I kept some AJAX heavy sites(Facebook, Google Analytics) open or when I had all of my favourite add-ons. After half an hour, it felt slower than FF3.6.
- FF5b2 stayed up 5 days even with the AJAX have sites in some tabs and most of my add-ons. Big improvment! However short before "the end", it hat 1.7 GB virtual and 0.9 GB commited and the GUI got unresponsive gain. The shutdown of this beast FF5 took 2 minutes to succeed, creating a spike memory usage of 1.8 GB virtual, 1.0 GB private. Opening about:memory did not really work any more at this time, I mean I got impatient waiting, I'll try next time.

Please hunt down more of those memory leaks!

Comment 35

[Roman R.]

(In reply to comment #27)
> Well, FF5b2 is really doing way better in my environment. This is great!
> I'll abandon FF4 now for me, it never was "stable" in my world.

In my experience, FF 5 is worse than 4.0.1. I am currently running the 2011-06-11 build. 32-bit Windows 7.

Comment 36

[Nicholas Nethercote [inactive]]

(In reply to comment #35)
> 
> In my experience, FF 5 is worse than 4.0.1. I am currently running the
> 2011-06-11 build. 32-bit Windows 7.

Can you give details, e.g. any particular website you notice this on?  I've heard numerous people say FF5 is better than FF4/4.01, you're the first I've heard say the opposite.

Comment 37

[MOW]

JFTR, while the problem with the GC not triggering might still be present in 5.0, the leak rate has been reduced so drastically that it's not such a pressing problem anymore. It's a line of defense gone bad, but the leaking should't have been so bad in the first place.
5.0 actually is better than 3.6 was in terms of process lifetime before the browser gets so sluggish it needs a restart. This one is running since 2011-05-27 now. Time will tell if it reaches the 1-2 months between restarts I got with 3.0/3.5.
Okay, that was easy to do with 3.0 because it had a much smaller memory footprint at startup and would take some time to grow beyond my physical RAM, whereas 4.0 onward hits the swap almost immediately, but doesn't actually seem to actively use most of it when it just sits around, which is quite different for 3.0 when it outgrows physical RAM. Guess I'll have to wait a few weeks to see what 5.0b2 does when the remaining leaks have accumulated.

With 4.0.x, the leaks were so bad even in an idle browser with minimized windows that I could see its memory usage continually rise in TaskManager, without ever going back down. Now, the browser just sits there, not increasing for several minutes, if at all. Even after more than 1 day the increase in memory is less than 100MB - which might be below the gc trigger, so I can't tell for sure if the auto-gc works or not, but the machine is in no danger of running out of space and doesn't take 25 minutes for the "welcome back" gc, so I can live with that.

And that's with basically the same session and all of the plugins and addons - except one addon that FF5 didn't accept (B-O-M), but since that one was initially deactivated in 4.0 also with the problem already showing I wouldn't think it has anything to do with this.

tl;dr: 5.0 good, 4.0 bad.

Comment 38

[Roman R.]

(In reply to comment #36)
> Can you give details, e.g. any particular website you notice this on?

I can't pinpoint a single website because I always have tens of open tabs. Lately, when I started testing the nightlies, Firefox starts at around 500+ MB and reaches 800 - 900 MB and more in several hours, so I have restart it. (And I launch it with JavaScript disabled in order to reduce resource consumption.)

Comment 39

[Nicholas Nethercote [inactive]]

I'm going to close this bug, because it has become a big mess.  I've spun off two bugs (bug 666101 and bug 666103) for the two cases where steps to reproduce were precise enough to be useful (eg. a specific URL was named).