Closed Bug 510854 Opened 16 years ago Closed 13 years ago

Firefox eats memory on Google pages while the PC is idle

Categories

(Firefox :: General, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: lecotegougdelaforce, Unassigned)

References

()

Details

(Keywords: perf)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.0.13) Gecko/2009080317 Fedora/3.0.13-1.fc10 Firefox/3.0.13 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.0.13) Gecko/2009080317 Fedora/3.0.13-1.fc10 Firefox/3.0.13 I use to let my session opened during the night on my working computer, usually with firefox and a few tabs opened. At the moment I leave, Firefox will use about 35% of my 1GB RAM, which is already quite enormous IMO. When I come back on the morning, it uses more than 60%. Just starting to use the computer (and firefox) again will make it lose a few percents (it is currently at 55% after a few minutes). Reproducible: Always Steps to Reproduce: 1. Open a few tabs in firefox. 2. Wait half a day. 3. Check memory usage. Actual Results: Firefox will use about twice as much memory it used 12 hours earlier. Expected Results: Firefox should use no more than the same amount of memory.
Forgot to mention bugs #413399 and #470969, which are quite old but seem to address the same issue. There are probably some duplicates, but I don't have time to browse the billion of bug reports related to firefox memory usage…
Just to mention that after some normal computer usage, web browsing and new tabs opened (no closed tabs) firefox memory usage has now "fallen down" to about 43% — which is still far more than it should, but I think this fact could help finding the memory leak.
- what where the URLs in those tabs (how else can this be tested ????) - what are your extensions (Flash etc ... consume a lot of memory !) - does it also occur in Firefox 3.5 (which uses less memeory) You might not have to time to read all those existing reports, or to do hunt after the bug itself, but a report like "I have a leak, please fix it" doesn't work either.
(In reply to comment #3) > - what where the URLs in those tabs (how else can this be tested ????) Happens whatever the URLs. > - what are your extensions (Flash etc ... consume a lot of memory !) Mmh… Is there an easy way to provide this information, like about:plugins but for extensions ? Would be nice… A way to export about:plugins as well. Worth a wishlist report ? Anyway : # Extensions : -Adblock+ 1.1 -HunSpell 2.0 -DownloadHelper 4.5 -FlashBlock 1.5.11.2 -GreaseMonkey 0.8.20090123.1 -Novel Moonlight 1.0.1 # Plugins : Java(TM) Plug-in 1.6.0_11-b03 Silverlight Plug-In Totem Web Browser Plugin 2.24.3 VLC Multimedia Plugin (compatible Totem 2.24.3) Windows Media Player Plug-in 10 (compatible; Totem) DivX® Web Player QuickTime Plug-in 7.2.0 Shockwave Flash NPAPI Plugins Wrapper 1.3.0 I will try to disable them tonight (and uninstall some which I don't use anyway), we'll see if it improves. > - does it also occur in Firefox 3.5 (which uses less memeory) Didn't noticed that it was not Firefox 3.5 actually, since I updated it to 3.5 two days ago at home and was supposed to be up-to-date here. I'll check my home install, but it seems to be the same since it was using 39.2% of memory a few minutes ago when I checked your message, and is at 40.9% now, while nobody is using it and only 4 tabs are opened if I remember well. > You might not have to time to read all those existing reports, or to do hunt > after the bug itself, but a report like "I have a leak, please fix it" doesn't > work either. 1. It was intended to be a tease since Firefox is known to use way too much memory. Actually, if you search for "memory" in bugzilla it will only show you 200 results, so anyway if I wanted I could not check all related bug reports. Which does not mean Firefox isn't the best browser anyway, since it's the one I use. 2. As you can see I checked anyway, see first comment. 3. I am happy to provide any information I can, any request for more information is welcome. I'm not a Firefox developper so I am not supposed to know which information are needed. Now, if you don't want to fix bugs, it's up to you… So let's keep it easy, please. ;)
There is also a known leak, see bug 478823. It must be extension related or URL related. Without extensions, with a simple page, is very unlikely to leak.
Thanks for pointing out this bug, it seems to be the very same issue. However, I can't find the navigator.plugins.refresh() function on any javascript file of the websites which I remember were opened (on elog on restricted access (see https://midas.psi.ch/elog/), three google books (for instance http://books.google.com/books?id=NidkFGzUINcC&pg=PA265&lpg=PA265&dq=Alessandro+Melchiorri+Francesco+De+Bernardis+Luca+Pagano+and+Paolo+Serra&source=bl&ots=rygLIFOqos&sig=k54F7uz_PTdsrZU2LC3kaYxHPIE&hl=en&ei=C2uFSuT3JpCTsAbg1eH_Bw&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false), and http://wmap.gsfc.nasa.gov/universe/bb_tests_ele.html). And as I said, it seems to happen at least with many websites. I will try the suggestions in the other report tonight, and check the websites opened at home (where now firefox is using 53.8% of memory, while it is now at "only" 36.5% here with the same tabs as this morning still opened and 13 new tabs).
All three sites are pretty stable on 3.5.2. on XP. Waited for minutes and didn't see any increase. Also when I have them all three together in different tabs.
Yes, that's what is weird : currently I have 20 tabs opened, those sites included, and everything works properly with an overall memory consumption of 33% (of 1GB). If I leave the computer for several hours, it will increase. If I come back and play with the computer without even closing these tabs, it will decrease. That's why I didn't think it could be URL-related, it seems to have more to do with the system itself. I thought of web crawling or whatever. BTW, forgot to mention I'm using an up-to-date Fedora 10. Tests at home (now 57.6%, if you want to plot the evolution… :P) are done under an up-to-date Arch Linux.
I have it leaking now, still analyzing.
The books google page is my suspect. Open the same page in 10 tabs and I see something in the taskbar. But I am not entirely sure. If I do something with FF, the memory use drops again. Lucas
I set this bug to NEW. It is the books google page, but behavior is strange. When I open 20 tabs of that page, it starts soaking up memory. But when I do something with FF the memory gets freed again (although some memory may not be released). Next step is to look which part of the page is doing active things. It is a rather static page. Lucas
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have to mention that I'm 100% sure that I don't have any google books page opened at home (I can check what is opened if it can be checked in command line, otherwise you'll have to wait a couple of hours), where FF is now using 62.7% of the memory. So if it is website-related, it must be a quite frequent "feature". BTW, in case it can help, according to today's data from my home, the leaking is wonderfully (almost perfectly) linear as a function of the CPU time.
(In reply to comment #5) > There is also a known leak, see bug 478823. > > It must be extension related or URL related. Without extensions, with a simple > page, is very unlikely to leak. Normally I wouldn't think it's the same issue, unless there's an extension, a plugin or the javascript in the page calls navigator.plugins.refresh, which is not so common. However, in Lucas's case, the second URL (<http://technet.microsoft.com/en-au/library/cc917718.aspx>) calls navigator.plugins.refresh in one of the pieces of JavaScript, but in a location that is executed when the SilverLight plugin is installed. Skippy, I guess that disabling the SilverLight plugin is a workaround for your case.
Status: NEW → UNCONFIRMED
Ever confirmed: false
No, it is not the navigator.plugins.refresh call. You can check that by opening the window. When such refresh is called, the window is also refreshed. It is not the case for the books google page. It reproduces also in Safe Mode and in a single tab. With a single tab the leakage is about 4kb a second in a steady page. But you have to wait quite long before it starts (20 tabs starts much faster). And as I said before, if you do something with FF large (maybe all) memory is released. Lucas
Jo, why do you make this unconfirmed? Open 20 tabs books google page of comment #6 and you will see the behavior.
Skippy at #12: It is not so important to speculate about the root cause. The Mozilla engineers will find that. Important is that there is a 100% reproducible scenario. If it is 100% reproducible, then a good engineer can find the root cause in one or two days. But, one can search for months to a problem that doesn't reproduce very well. If it is on Google page, then it may appear on many more sites. Google is everywhere (like Big Brother :-) Lucas
Sorry, got 2 updates at the same time going on - I didn't see the warning page either (otherwise the "Ever Confirmed" flag wouldn't have bveen restored). But it's not a race to get this confirmed, we first have to see what is really the problem. As far as I can see the google books page doesn't a plugins.refresh anywhere, it might be a different problem that your bug. Don't forget that we're checking here against multiple versions of the same browser (and creating new profiles every time).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, okay. The NEW is important, because not because of a race, but then Mozilla engineers may pick it up. Skippy, if you have other sites, that would be helpful. But I am quite sure that it is URL related. If I open the Nasa site 20 times, it doesn't reproduce. So, if you suspect a site, open it 20 (or more) times in your browser (without any other pages) and see if it reproduces. If so, report the site here. Lucas
Here are the links that were opened at home : http://www.universfreebox.com/article8828.html http://www.dailymotion.com/user/mozinor/video/x9zorz_francois-simon-teste-le-ghb-parodie_fun http://fr.mc283.mail.yahoo.com/mc/welcome As soon as I left gnome-screensaver, FF memory usage dropped to 11%. I left my work computer on with add-ons disabled from --safe-mode option, and just one tab opened on google homepage, we'll see what happen, it's currently using 5.9% of memory. Using FF 3.5.2 here on Arch Linux as previously mentionned : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090804 Firefox/3.0.5
I can't reproduce it on those sites. Maybe those are Linux related. I can't load the French yahoo page. It will redirect to my own Yahoo mailbox.
This is really bad. I can reproduce this on www.google.nl (it will redirect me there, but it probably also reproduces on www.google.com). It reproduces when I am logged in, but also when I am logged out. Open new Firefox session (to start with low memory fragmentation). I opened about 30 tabs on www.google.nl. I opened taskbar. Nothing happens. However, when I waited some minutes (and I really mean minutes), suddenly a leaking behavior was shown. I didn't touch anything about the PC. I can't reproduce this on any of the other sides. It is Google related. Since Google is such major site, I marked this bug now critical. It is not uncommon that people keep the google main page open on their PC. Lucas
Severity: major → critical
Keywords: testcase-wanted
OS: Linux → All
Summary: Firefox will eat memory during the night while the PC is idle → Firefox eats memory on Google pages while the PC is idle
I confirm for google.com : firefox memory usage on my work computer (only 1 tab opened, on google.com, in safe-mode, see comment #19) has slowly but surely increased yesterday evening from 5.9 to 6.0 then 6.1 and is now at 7.1%. On my home computer, as I lost my network connection yesterday evening, I made a silly test : a bunch of tabs (I mean really a bunch, something like 50 or more) opened on nothing, still in safe-mode. No effect on the memory usage. When I leave for work I will test one tab with another webpage than google.com.
It is not JIT related. I have the same behavior when I turn off JIT. I also checked the main page of the Wikipedia. The problem didn't pop up. I can only reproduce this on the Google pages. With 20 tabs of the main page, it takes about 3 to 4 minutes, before the odd memory behavior starts. #22 Your test was not silly. You tested a specific situation and that is good. A really Silly test is: - You do something I don't know when the test passes or not. A little bit less silly test, but still silly is: - You do something, you know when the test passes or not, but it doesn't narrow down the problem. So, you result is still useless. Lucas
It doesn't reproduce when I make a local copy. It also doesn't reproduce when I load local copy with Apache server between it. It doesn't reproduce when I turn off Javascript entirely. It still reproduces when I turn off cookies or form/search history. Lucas
The problem might be solved with bug 506125. Anyone with a trunk build is invited to check.
Why did you you say that ? You posted this, while you should know that it's not available on the regular nightly build. It was on a *tracemonkey* branch build (bug 506125 is called "Experiment with memory-pressure-based GC scheduler" for a reason), not on the trunk. And it was reversed 20 minutes later anyway, which is a full 16 hours before you commented on it. Were you actually able to confirm that bug 506125 fixes this particular problem, or were you just guessing ?
Oh sorry, I do not know all the details of builds.
skippy, I don't see problems with most google pages. specifically which google.com URLs cause problems?
See comments 21 and 22 : Lucas reproduced it with http://www.google.nl and I did with http://www.google.com. BTW, just for information, this bug also seems to occur on a Debian Lenny with Iceweasel 3.0.6-3.
please install https://addons.mozilla.org/en-US/firefox/addon/2490 and report results of leak monitor
Severity: critical → major
Keywords: perf
Thanks for pointing out this extension. [For the records, it won't work out of the box for Firefox 3.0.15, you have to trick the versions in the file install.rdf in the .xpi file (which is nothing but a .zip file)] Here is what I have done : 1/ Open firefox with a blank profile with google.com as homepage and leak monitor enabled. 2/ Open a new window (thus also with google.com). 3/ Close the new window. Then 4 popups opened, containing respectively the following : ------------ First popup ------------ Leaks in window 0x9bc6140: [ ] [leaked object] (9bc6140) = [ChromeWindow] ------------ Second popup ------------ Leaks in window 0x9bca980: [ ] [leaked object] (9bca980) = [ChromeWindow] ------------ Third popup ------------ Leaks in window 0xa76d120: [ ] [leaked object] (a863780, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 116-116) = [Function] [ ] [leaked object] (a859ae0, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 30-30) = [Function] [ ] [leaked object] (a859b00, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 31-31) = [Function] [ ] [leaked object] (a76d120) = [Window] [ ] [leaked object] (a859e60, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 47-47) = [Function] [ ] [leaked object] (a878540, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 155-156) = [Function] [ ] [leaked object] (a859c60, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 37-37) = [Function] [ ] [leaked object] (a861800, http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js, 73-73) = [Function] ------------ Fourth popup ------------ Leaks in window 0xa420560: [ ] [leaked object] (a420560) = [Window] Then as I started filling the login field on this bug report, 4 new blank popups occured, which I don't know wether they are related to the window closing or to the field filling (many times I have observed huuuuge CPU consumption when filling webpages fields ; I was about to file a bug report once but couldn't reproduce after a fontsize change — who said weird ?) : ------------ Fourth popup ------------ Leaks in window 0x9bc6140: ------------ Fourth popup ------------ Leaks in window 0xa420560: ------------ Fourth popup ------------ Leaks in window 0xa76d120: ------------ Fourth popup ------------ Leaks in window 0x9bca980:
Mmmh, just figured out that the 4 last popups concerned the 4 first leaks (same addresses) and were labeled something like "warning for memory leak recovery" instead of "new warning for memory leak" (rough translated from French).
I retried it with FF 3.6 and I can't reproduce it anymore. I opened 25 Google tabs and waited for 7 minutes, but nothing happened. Maybe the problem isn't on Google anymore or FF has been changed. As said earlier, it could be the garbage collector not kicking in. Still, this can be annoying, if you leave your computer and all the memory has been soaked just because the GC didn't start.
Yeah Lucas, very very annoying!! If you or (anyone else) want to, see the <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=525694" title="RESOLVED DUPLICATE - A memory leak that occurs when Firefox is left running with 10-15 tabs with Google search results open.">Bug 525694</a></span> that I've submitted back then (it's a duplicate of this bug).
The problem still exists on Google side, I checked this afternoon. See the leak monitor report on comment 33, the script http://www.google.com/extern_js/f/CgJlbiswCjhSQAgsKzAOOAssKzAWOBcsKzAXOAUsKzAYOAUsKzAZOBIsKzAdOCIsKzAlOMmIASwrMCY4CSwrMCc4BCwrMCo4AywrMCs4CiwrMDw4AiwrMEA4BiwrMEQ4ASwrMEU4ASw/4NS0YsldJO0.js may be related ? So if it has been solved, I think it is on firefox's side from 3.5 to 3.6. Anything relevant in the changelog ?
can you reproduce this current beta http://www.mozilla.com/en-US/firefox/beta/ or most recent nightly - b8pre? ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
Memory usage steadily climbs on Google Documents as well. If I open up a document, the memory usage is low at first but steadily climbs up. I've seen Firefox jump to 350 before.
Could you try with a newer version of Firefox? Like 8 or 9?
Just made a test with a clean profile and Firefox 14.0.1 on Fedora 16 (Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1). I opened a bunch of google.com, google.nl and google books tabs (something like 80 tabs in total), then disabled power management and let it like that for the night, monitoring firefox with "top" every second. Attached is the monitoring logfile. Seems that the memory usage still increases, but at some time is reset, many times along the night. (Note that the "TIME+" column does not show actual time, didn't investigate that but maybe it's worth mentionning it : the logfile lasted only between 11 and 12 hours.)
does look like it "resets". So close WORKSFORME?
I won't close it myself as I cannot say if a periodical reset is a satisfactory solution regarding Firefox memory management policy, but I won't push either since whatever the dirtyness of the solution, on the user side the bug appears as fixed anyway (situations in which the memory usage increases too much before a reset are probably unrealistic).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: