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)

Product:
Firefox
Component:
General
Version:
4.0 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 659856

People

(Reporter: mail, Unassigned)

References

Details

(Keywords: memory-leak, Whiteboard: [MemShrink:P2])

Attachments

(2 files)

Firefox 4 memory usage in Windows Task Manager
3.39 KB, image/png
Details
Display of the about:memory page
29.58 KB, image/png
Details 
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 #4)
The GMail Issue could be Bug 497808.
Blocks: mlk-fx5+
Keywords: mlk
Hardware: x86_64 → x86
Version: unspecified → 4.0 Branch
(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).
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.
No longer blocks: mlk-fx5+
Whiteboard: [MemShrink:P2]
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!
(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.
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.
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: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: