Closed Bug 645633 Opened 11 years ago Closed 11 years ago
Firefox 4 consumes more than 1
.9 GB memory after some hours runtime (memory leak?)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 After approximately 8 hours runtime (even without any action) Firefox 4 consumes more than 1.9 GB memory on my system. During this time it is not necessary to do anything with Firefox; just open it and let it open. I've got five tabs open in background (Panorama). Firefox 4 behaves this way since Beta 9 or so; meanwhile I thought the problem was gone. Reproducible: Always Steps to Reproduce: 1. start Firefox 4 2. leave it open some hours Actual Results: approx. 1.9 GB of memory usage, increasing with time
This sounds serious. I will try to reproduce on a test machine and come back later with some results. In the meantime, you can do it again yourself if you have the time and resources. Thanks!
I will help for sure. Is there something I can do if the problem arises again which could help you by the troubleshooting?
I can verify this on a vanilla, brand-new (no existing profile) FF4 installation with absolutely no installed addons. This is on 64-bit Win7 (running the official 32-bit FF4, of course). However, my method of reproducing the bug is: start FF4, open up a gmail tab, and leave it alone. If you use Process Explorer to watch the FF4 process, the Working Set size grows by 1-2MB/minute. It's not a fast leak, but it's consistent. I just had FF4 hang on me with a 2.9GB Working Set size (I never knew that 32-bit FF4 could use up this much memory).
(In reply to comment #5) Bug 497808 sure sounds like my problem, but I've never seen a slowdown or hang/pause. However, wouldn't this also affect FF3.6 (I did see annoying pauses there)? While I did see memory growth in FF3.6, it would take a week or so to grow to the size that FF4 grows in a day. Anyway, I started my plain vanilla FF4, and just let it run. Initially, the private bytes size was 33.6MB. After nearly 3 hours, it's now 89.6MB. However, I'm not sure if this is actually significant, as it's not really that much of an increase. I'll let it keep on running overnight, and we'll see if it's significantly larger in the morning.
In my experience, memory usage of around 130MB can be considered normal after a few hours. Most of the cost here comes from js/gc-heap (should level off around 115MB) and storage/sqlite/pagecache (levels off around 55MB) are the main cause of this. I would say that to know you have a leak when using one tab it would have to pass 200MB before calling it a leak. The 2.9GB usage for a 32bit process sound about right for a win7 x84_64 machine. The earlier versions of windows had caps of 2GB per process even if there was more RAM. They had a flag which allowed up to 3GB per 32bit process and I beleive that this flag is default on (some) windows 7 versions. Also check out that you are not being heavily affected by other memory leaks in bug 640452 since things like having the window minimized during a test can affect results (bug 638238).
Firefox 4 uses 1.5 GB of memory actually on my system. Here is what I found at about:memory (attached screenshot). Runtime approx. 10 hours, 6 tabs permanently in background open (Panorama): <http://www.linuxlibertine.org/index.php?id=86> <http://test.elmastudio.de/> <http://www.drweb.de/magazin/html5-ueberblick/> <http://net.tutsplus.com/tutorials/html-css-techniques/html-5-and-css-3-the-techniques-youll-soon-be-using/> <http://www.saechsdsb.de/ipmask> <http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF>
After closing five background tabs (Panorama) yesterday, Firefox 4 hasn't increased its memory size during the night (approx. 9 hours). The closed tabs were <http://www.linuxlibertine.org/index.php?id=86> <http://test.elmastudio.de/> <http://www.drweb.de/magazin/html5-ueberblick/> <http://net.tutsplus.com/tutorials/html-css-techniques/html-5-and-css-3-the-techniques-youll-soon-be-using/> So I suppose that one of them has been the reason for the memory leak.
Sorry for the inconvenience: 4 tabs were closed, not five.
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)
(In reply to comment #9) > After closing five background tabs (Panorama) yesterday, Firefox 4 hasn't > increased its memory size during the night (approx. 9 hours). The closed tabs > were > > <http://www.linuxlibertine.org/index.php?id=86> > <http://test.elmastudio.de/> > <http://www.drweb.de/magazin/html5-ueberblick/> > <http://net.tutsplus.com/tutorials/html-css-techniques/html-5-and-css-3-the-techniques-youll-soon-be-using/> > > So I suppose that one of them has been the reason for the memory leak. Interesting. Can you narrow it down any more? Can you try grabbing cycle-collector dumps over time and see if they keep increasing in size? https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump
(In reply to comment #12) > Interesting. Can you narrow it down any more? > > Can you try grabbing cycle-collector dumps over time and see if they keep > increasing in size? > https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump Hi, I'll try this at the weekend and report the results here.
(The attachment was too big, so I've uploaded it on my own webspace here: <https://tools.rene-schwarz.com/demos/ff4-bug545633-memory-leak-capturing.rar>) Today I had time to write a short program capturing the memory information of a running Firefox process. There is a CSV file in the attachment showing the Time (UNIX Timestamp), Virtual Memory Requested, Private Memory, Paged System Memory, Nonpaged System Memory, Paged Memory, Peak Paged Memory, Peak Virtual Memory, Peak Working Set, Minimum Working Set, Working Set of Firefox during three hours. In this time, Firefox increases memory size to 949 MB. I've made three cycle-collector dumps, as requested (in the attachment, too). During the three hours Firefox was only used for evaluating the code for the cycle-collector dumps, to open three web pages and some few tab switches. At the moment I have no time to let Firefox open; but it is the same behavior as reported before: The memory consumption is increasing over the time with the pages named above loaded in background. Does this information help you?
I am also facing the similar issue on Ubuntu 11.04, here are the top details. I have 2 Gig of RAM and running 64-bit OS. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20136 fazlur 20 0 1536m 685m 24m S 9 34.2 13:42.64 firefox-bin
I am also facing the similar issue on Ubuntu 11.04, here are the top details. I have 2 Gig of RAM and running 64-bit OS. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20136 fazlur 20 0 1536m 685m 24m S 9 34.2 13:42.64 firefox-bin Any workarounds/fix for this issue. As i use the firefox more frequently, i am more dependent on it.
Looks like the same issue I'm having. 1-2 MB/minute is exactly the rate of memory leak I'm seeing, regardless of how many tabs I have open. The program tends to crash at around 2 GB of RAM usage. My system is 64-bit, running Windows 7. Never had this problem in Firefox 3.6, though I seem to recall a similar problem in much earlier versions.
To everyone who has commented in this bug: Firefox 5 (beta) has better memory behaviour than Firefox 4, see http://blog.mozilla.com/nnethercote/2011/05/25/firefox-5-has-fewer-leaks-than-firefox-4/ You can get it from http://beta.mozilla.org. Reports about whether this fixes or does not fix your problems would be welcome.
nicole.baumann, can you check if the problem still occurs with a nightly build? It sound like it might be bug 654106 which is fixed on trunk. If it's not fixed on trunk, can you please make one of those test pages publicly available? A test page that causes constantly growing memory is *exactly* the sort of bug report we want!
(In reply to comment #20) > nicole.baumann, can you check if the problem still occurs with a nightly > build? It sound like it might be bug 654106 which is fixed on trunk. You can get a Nightly build from nightly.mozilla.org.
I can definitely get a memory rise with the code in comment 22 even just using the 'some.cgi not found' error page from my server. It can be made faster by changing the 100ms to 0ms. Observations in Nightly: - memory goes into heap-unclassified. - memory released by a GC (caused by reload of about:memory or other method). Given my results I think the testcase in comment 22 is caused by bug 656120.
My observation: Memory consumption rises dramatically on slow and unreliable connections like UMTS on a train. Nightly build 7.0a1 from 2011-06-14 is not any better than 4.01
This bug has become a mess. I've spun off bug 666104 and bug 666105 for the two cases where precise steps to reproduce were given. To everyone who commented: you might like to try Firefox 5 (newly released) which fixes various leaks in Firefox 4. Even better, you could try a nightly build (from nightly.mozilla.org) which fixes even more. If you still have problems, feel free to file a new report, but please give more specific steps to reproduce, eg. a specific website(s) that demonstrate the problem. If you don't do that, it's unlikely the bug report will ever be resolved.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: mlk-fx4
You need to log in before you can comment on or make changes to this bug.