For quite some time now, I've been noticing that FF is growing to a huge memory footprint. I just figure out today that this is happening when I have a tab open with the gmail Inbox showing. I'm currently running 2006060105, but an even more recent version at home has a similar problem. With gmail open, I can watch the working set grow fairly rapidly in the task manager (and it isn't just a task manager quirk, because I'm actually using Sysinternals Process Explorer). If I close the gmail tab, it stops growing.

I can confirm this. Mozilla is using several 100MB's after I've left it open for a night. I can't see it in a 2006-01-20 build, so this regressed at least after that date.

at least 1 large leak was fixed in bug 206520

Now works for me with 2006061405.

I would like to reopen this bug, if you don't mind. Iirc, I saw this bug still with a 2006-06-15 trunk build, that is after your build which you said was wfm. So far, I have found out that I don't get the memory eating with a 2006-05-01 build, but I do get the memory eating with a 2006-05-15 build.

Ria, do you see this bug too? Like when GMail has been on all night, do you get to see Firefox trunk using 100MB's of memory? I think now that this regressed between 2006-05-04 and 2006-05-08.

(In reply to comment #5) > A night is too much (electricity bill) but I can leave a browser open for 4 or 5 hours and report back.

My regression range is a bit different: 1.9a1_2006051010 - 1.9a1_2006051022 (tried them both 2 two times 5 minutes) but both leak 4 DOM windows using the leak gauge. Maybe I should re-check tomorrow.

Yes, I keep getting the same results. The starting value of the first build is also about 3 MB lower than the second build. The latter grows 1 MB in about 3 to 4 minutes. That would mean this: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-10+09%3A00&maxdate=2006-05-10+23%3A00

Ok, thank you, Ria. I just retried a 2006-05-08 trunk build, and I don't get increased memory usage, so my previous perception in comment 5 was wrong. I believe the regression range you are getting. That means this is probably a regression from bug 326273, I guess.

I was just about to reopen this myself. I believe I'm still seeing the bug now too (updated to 2006061904 in the mean time). I'm not sure why it looked like it had gone away before. Perhaps an intermediate bug fix caused a delay before the leak starts being apparent (previously I could launch FF, bring up gmail, and immediately see rapid memory growth, now that doesn't happen but FF is still huge when I come back the next morning).

-> me, for investigation

It doesn't look like it's specific to gmail, I can see this with http://www.lemonde.fr for instance. See also bug 340260.

happens also in contacts and compose, not just inbox - for me at ~260k/min. does not happen with google calendar. Loss in seamonkey is a few k/min (almost zero). there is an initial delay (approaching one minute) before memory starts climbing, similar to bug 342810 - rather odd. might this be java related, in addition to the connection to threadmanager checkin?

(In reply to comment #13) > happens also in contacts and compose, not just inbox - for me at ~260k/min. > does not happen with google calendar. Loss in seamonkey is a few k/min (almost zero). correction - SM with gecko 1.9 has same problem. (I tested wrong SM)

*** Bug 344438 has been marked as a duplicate of this bug. ***

bump description with "memory"

Greetings, Firefox 2.0.0.1, gmail 'standard with chat'. I demoed this to some coworkers today; I had a gmail tab which I'd left open over the weekend. The browser as a whole had grown to 883M of memory usage. I closed the gmail, and a few moments later the browser dropped to 585M. That was about a 300M drop for a single tab closing. Now I don't know if the gmail JS is behaving badly (preserving XMLHttpRequest responses in some way that doesn't allow for Javascript collection?) or if Firefox is behaving badly (holding onto rendering information after the DOM object has been replaced? Or a million other things...) but there is a definitely bad interaction between the two over time. I left a browser running with a gmail tab over the holiday vacation, and came back to a 1.8G Firefox process, which stopped nearly cold every time I tried to click on a dropdown, or most form elements, and was slow overall. I didn't think to just kill the gmail tab back then, and just restarted FF (which reloaded its sessions and all windows and tabs at about 220M). Time seems to be the best way to replicate this, unfortunately. I know it's all anecdotal supporting information, but hopefully it's useful.

Morgan, you're seeing a different bug, this bug is about a regression in the latest trunk builds that causes memory to grow with gmail. You are using a branch build, so it has to be something else that causes the memory growth on your computer.

Dbaron, can you take a look at this?

I have also experienced this problem, not just on FF but also on IE7. My investigation leads me to believe that Gmail is repeatedly creating an anonymous function and assigning it to an event. I think that is the cause of the "leak". That investigation was several months ago, so I'm going to have to redo it to make sure I am correct.

Could someone check if bug 342810 ("2007-06-07 14:41") checkin solved this bug too ?

Yeah, this seems fixed now. I can't reproduce it with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070612 Minefield/3.0a6pre I'm marking it worksforme, because I haven't tried it with a build prior to the fix for bug 342810. If someone wants to mark this fixed, then he should do that.

Tried 20070613 and it seems (so far, cross fingers :-) to be working for me too. Woohoo! I will consider this fixed unless longer term testing shows it's just delayed or something (that's happened before with this issue). And on exactly the 1 year anniversary of the bug being entered, too :-)... maybe we should have a party.

--> WORKSFORME (FIXED is only used when a known patch fixes a known problem)

Stevee in comment #24 > --> WORKSFORME (FIXED is only used when a known patch fixes a known problem) rather than assume everything we've done and know thus far is bogus and changing it to WFM, it would be more useful to ask ray if it fails on 2007-06-06 build. Ray, can you test the -06 or -05 nightly? And if it fails on those builds then change this back to FIXED please. thanks.

Whatever... it's been a known problem for me and many others for more than a year (to the point where I have had to close and reopen Firefox every day when I get in to work just to be able to use it at all), present in all the frequently updated nightlies that I've tried over that time, up until just now, when coincidentally it's suddenly not happening any more. I suppose technically WFM is the correct resolution for the mysterious disappearance of a widely known and reported bug that's exactly correlated to a patch designed to fix a similar problem, but somehow "fixed" seemed more confidence-inducing. But as I said... whatever. I'm just happy it's fixed^H^H^H^H^Hmysteriously working for me now. I'll try 06 after I get more confidence that this version really is working (and get a chance to enjoy it for a couple of days :-).

(In reply to comment #26) > I suppose technically > WFM is the correct resolution for the mysterious disappearance of a widely > known and reported bug that's exactly correlated to a patch designed to fix a > similar problem, but somehow "fixed" seemed more confidence-inducing. It's far more than that. Determining if 342810 fixed this bug helps define the scope of the original problem, i.e. 342810. Further, defining scope and symptoms (in this case beyond the realm of flash) potentially helps triaging of other bugs. So I look forward to Ray's test, because whatever the results may be it will be useful information. Besides, I didn't spend time researching and commenting in flash and other bugs for the past x months just to see relevant bugs needlessly changed to WFM.

Would you mind taking this debate elsewhere? Unless you'd prefer that everybody receiving the resulting bugmail read that rather than working on other bugs that actually still exist...

I'm running the 6/6 build now to check this, but it just now occurs to me that this is very likely to be the same issue because the gmail page has a flash sound file (swf) embedded in it that it uses for its alerts. I'll report back on my memory usage after the weekend.

Ok, I've tested the 6/6 build, and it still shows the (relatively) rapid memory leak (up over 600k VM since yesterday) that more recently builds don't have. I will say that the 6/13 build still seems to have some very slow leak that makes it grow (to a relatively reasonable ~300k VM) over the course of using it for a week, but it's completely bearable. Based on this information (and my plausible explanation that the gmail page does, indeed, contain flash), I'm going to mark this FIXED again... but that's my last word on it so if anyone feels strongly about it being WFM I'm not going to argue. <breaths a sigh of relief as he reinstalls the latest nightly>

Thanks for checking, Ray!

(Reading back up, this would appear to have been fixed by bug 342810.)