Closed
Bug 645633
Opened 14 years ago
Closed 13 years ago
Firefox 4 consumes more than 1.9 GB memory after some hours runtime (memory leak?)
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 659856
People
(Reporter: mail, Unassigned)
References
Details
(Keywords: memory-leak, Whiteboard: [MemShrink:P2])
Attachments
(2 files)
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
Reporter | ||
Comment 1•14 years ago
|
||
Comment 2•14 years ago
|
||
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!
Reporter | ||
Comment 3•14 years ago
|
||
I will help for sure. Is there something I can do if the problem arises again which could help you by the troubleshooting?
Comment 4•14 years ago
|
||
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).
Comment 5•14 years ago
|
||
(In reply to comment #4)
The GMail Issue could be Bug 497808.
Updated•14 years ago
|
Comment 6•14 years ago
|
||
(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.
Comment 7•14 years ago
|
||
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).
Reporter | ||
Comment 8•14 years ago
|
||
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>
Reporter | ||
Comment 9•14 years ago
|
||
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.
Reporter | ||
Comment 10•14 years ago
|
||
Sorry for the inconvenience: 4 tabs were closed, not five.
Comment 11•14 years ago
|
||
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
Reporter | ||
Comment 13•14 years ago
|
||
(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.
Reporter | ||
Comment 14•14 years ago
|
||
(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?
Comment 15•13 years ago
|
||
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
Comment 16•13 years ago
|
||
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.
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
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.
Updated•13 years ago
|
Whiteboard: [MemShrink:P2]
Comment 19•13 years ago
|
||
I observe this problem since FF4.0/FF4.0.1 and still FF5Beta3 on Win7 64Bit.
In my case it's reproducable even with one tab. I have a site where setInterval, xmlHttpRequest and a DOMParser are used cyclically.
I name this javascript functions, because in small test pages where this functions are used, the problem still occurs, even if the memory usage grows much slower.
Open a new tab or close the thab or any other tab releases the memory, but when I keep Firefox open without any interaction after some seconds or minutes ( lets say: one minute) the memory usage will grow up and only parts of the memory get released.
When I interact again, the big memory block gets released, so that in most - when not all - cases, the memory level falls back to normal, where it was before the user inactivity.
Note: On some machines a crash occurs after few minutes of inactivity while on others, Firefox survives hours, maybe even a day.
Btw: It seems to me that bug report 652801 ( https://bugzilla.mozilla.org/show_bug.cgi?id=652801 ) is a duplicate.
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!
Comment 21•13 years ago
|
||
(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.
Comment 22•13 years ago
|
||
Thank you for the link!
I made some first tests but I definitly will have to do more for a valid statement.
The website itself shows a different memory alloc-release behavior:
Before in good cases the peaks all have nearly identically shapes, in bad cases the last release phase didn't exist.
Now in good cases even peaks and odd peaks have a different shape but all even looks similar and all odd looks similar.
But as the bad cases for the site gets less in FF5Beta3, it's still possible that there are some now.
However... here's one of my test-snippets with setInterval and xmlHttpRequest:
---------
<html>
<head>
<script type="text/javascript">
function handleStateChange()
{
// Do nothing with response whithin this test
}
function myFunc() {
var xmlHttpObject = new XMLHttpRequest();
// web service providing an xml response (about 139 Bytes), shouldn't matter in this case
xmlHttpObject.open('POST', '/some.cgi');
//
xmlHttpObject.onreadystatechange = handleStateChange;
// send some dummy data.. in my case about 42Bytes
xmlHttpObject.send(window.document + window.document );
}
IntervallId=setInterval("myFunc()",100);
</script>
</head>
<body>
<p>Test 1</p>
</body>
</html>
-----
Nightly Build started with 30.1 MB. I use the following Snippet and let it run for 15 minutes. The memory then was about 122MB. There was no user interaction in Firefox for this time.
This test site consumed memory in FF4.0.1, FF5Beta3 and Nightly Build (build date 14.Jun).
I don't know the result of FF3.6.x so far.
Comment 23•13 years ago
|
||
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.
Comment 24•13 years ago
|
||
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
Comment 25•13 years ago
|
||
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: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•