Last Comment Bug 664128 - JS heap grows continually when www.gamespot.com is left idle due to insufficiently frequent GC
: JS heap grows continually when www.gamespot.com is left idle due to insuffici...
Status: RESOLVED FIXED
[MemShrink:P2]
: footprint
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Windows Server 2003
: -- normal (vote)
: ---
Assigned To: Gregor Wagner [:gwagner]
:
Mentors:
http://www.gamespot.com/
Depends on: 656120
Blocks: mlk-fx4-beta
  Show dependency treegraph
 
Reported: 2011-06-14 07:04 PDT by Hector Wice
Modified: 2012-01-14 00:28 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
about:memory at the end of the test (869 bytes, text/plain)
2011-06-14 07:06 PDT, Hector Wice
no flags Details

Description Hector Wice 2011-06-14 07:04:07 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.2) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.91 Safari/534.30
Build Identifier: Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Firefox accumulates memory indefinitely after visiting a website.

Reproducible: Always

Steps to Reproduce:
1. Disable all plugins
2. Close Firefox
3. Start Firefox and check for enabled plugins. If there are such go to step 1, else close Firefox and continue to step 4
4. Start Firefox in safe mode
5. Maximize the Firefox window
6. Navigate to gamespot.com
7. Click "Click here to continue to GameSpot" on the page
8. Wait the next page to load fully
9. Minimize the Firefox window

Actual Results:  
Increase of the Firefox memory usage - after about 4 hours and 20 min the private memory of Firefox reached 500 MB. The following image obtained with Process Monitor shows the memory usage of Firefox for that time interval:

http://img221.imageshack.us/img221/2010/firefoxmemoryusage4hourb.png

Expected Results:  
Constant or near constant memory usage within a reasonable bound. I didn’t observe  accumulative memory usage pattern with Google Chrome 12.0.742.91.

I instructed Firefox to generate nspr log file in the beginning. Leak Gauge didn't find leaks in this log file. The attachment contains the information from about:memory obtained at the end of the test.
Comment 1 Hector Wice 2011-06-14 07:06:48 PDT
Created attachment 539190 [details]
about:memory at the end of the test
Comment 2 Matthias Versen [:Matti] 2011-06-14 09:10:01 PDT
Step7 isn't necessary for me to reach the main page.
I can confirm that the used memory increased from ~80mb to over 200mb until I stopped.
tested with FF4.01 and disabled plugins and in the safemode
Comment 3 Cork 2011-06-14 12:43:47 PDT
Sounds like this might be a dup of bug 656120.

The GC isn't triggered while firefox is idle. You could try the ff6 pre beta and see if the memory goes back down if you click GC + CC on about:memory.

It has to be done in ff6 as the update to about:memory didn't exist before.
Comment 4 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-14 22:15:11 PDT
Thanks for the precise steps to reproduce!
Comment 5 Hector Wice 2011-06-15 07:30:30 PDT
I performed two experiments.

Experiment 1
I disabled JavaScript from Tools -> Options -> Content -> Enable JavaScript, and performed the steps again. This time the private memory of Firefox did not exceed 84.7 MB for 11.5 hours:

http://img822.imageshack.us/img822/6978/firefoxmemoryusage115ho.png

Experiment 2
I installed Firefox 6.0a2 on Windows XP (x86) and repeated the steps. I used Windows Task Manager (Mem Usage column) to measure the memory usage of Firefox. The results (in chronological order) are:

97 Mb  – after loading the main page of gamespot.com
252 Mb – 1 hour and 15 min. later
235 Mb - after I restored the minimized Firefox window and pressed Cltr-t to open new tab
118 Mb – few seconds after I entered about:memory [Enter] in the location bar (in the new tab)
113 Mb - after I clicked the "GC + CC" button
104 Mb - 2-3 min. later
Comment 6 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-15 16:33:58 PDT
Hector, thanks for the detailed info, that's very helpful.

It's pretty clear the problem is due to insufficiently frequent GC:

- Attachment 539190 [details] shows that js/gc-heap accounts for 355,467,264 bytes out of 433,580,070 malloc/allocated

- Turning off JavaScript (comment 5) avoids the problem.

- GC does happen eventually (comment 5).

I talked to Gregor about this, he says that GC tends to happen quite infrequently, and that one would probably happen eventually due to heap growth.

So bug 656120 would help here, but the broader problem is that GC doesn't run often enough.
Comment 7 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-21 10:51:44 PDT
Hector, can you try a Nightly build?  Bug 656120 was fixed and that will hopefully help a lot.
Comment 8 Hector Wice 2011-06-23 02:08:47 PDT
I installed Firefox build from 22-Jun-2011 on Windows XP (x86) and performed the steps. The memory usage (Working Set) of Firefox did not exceed 141 Mb for 9 hours interval:

http://img24.imageshack.us/img24/9255/firefoxgamespotcom9h.png

The Kernel Time of the Firefox process at the end of the test was 24 minutes. What is the reason for this?
Comment 9 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-23 17:32:16 PDT
(In reply to comment #8)
> I installed Firefox build from 22-Jun-2011 on Windows XP (x86) and performed
> the steps. The memory usage (Working Set) of Firefox did not exceed 141 Mb
> for 9 hours interval:
> 
> http://img24.imageshack.us/img24/9255/firefoxgamespotcom9h.png

Great!  Time to declare victory :)

> The Kernel Time of the Firefox process at the end of the test was 24
> minutes. What is the reason for this?

I guess Firefox is making some system calls.  One possibility is the url-classifier, which periodically downloads new information about malware sites from a server.  See bug 650649 for more details.

Note You need to log in before you can comment on or make changes to this bug.