Closed Bug 644457 Opened 13 years ago Closed 13 years ago

Memory leak: closing gawker website tabs does not deallocate memory, add-ons may be involved

Categories

(Firefox :: General, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: jmcdon10, Unassigned)

References

Details

(Keywords: memory-leak)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

Firefox's memory use increases monotonically during browsing. I've had it up to 1.8GB with 3 tabs open.

I don't think this was a problem in RC1, but I only used RC1 for a day or two so I can't be sure.

Reproducible: Always

Steps to Reproduce:
1. Open Browser
2. Open every Gawker website: gawker.com, gizmodo.com, lifehacker.com, kotaku.com, jezebel.com, jalopnik.com, deadspin.com.
3. Weep as the pageouts begin; closing tabs does not save you.
Actual Results:  
For me doing it just now, memory use for firefox-bin increased from 14% to 42%, and dropped back down to 36% several minutes after closing the tabs. On net, browser memory use increased nearly a gigabyte.

Expected Results:  
Browser deallocates most of the 1.1 gigabytes it allocated to load those pages.

This is running on a Macbook Pro with OSX 10.6.6. I use noscript but I think I've allowed all the domains that gawker websItes use. I was also using a userstyle but I really doubt that's the problem (also this happens with regular browsing too but the Gawker sites are the worst).

I'm marking it critical because it makes the browser fairly unusable after a few hours, forcing the user to restart it regularly (or less savvy users to get very confused), and overall makes the browser considerably less competitive against Google Chrome.
It could be a problematic addon. 

In order to see if that's the case, could you see if the issue occurs if using Firefox in safe mode:
http://support.mozilla.com/kb/Safe+Mode

How about with a new, empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile
Blocks: mlk-fx5+
Keywords: mlk
Version: unspecified → Trunk
Note that safemode also disables the JavaScript JITs, so it may mask an important leak. Try a new profile.
By strange coincidence I was about to submit a similar bug. I had noticed that once FF4 settles down to a fairly constant memory usage (~400mb with 3 tabs open - google reader + two forums), gawker sites did not release all memory after their tabs were closed. About 30mb remained after 4 sites were opened and closed.

I suspect that this is made worse by ABP+noscript (I use them in combination and allow necessary script domains on gawker sites, with the fanboy list for ABP). 

I retested with a clean profile (only plugins were latest stable versions of DivX Web Player, Flash, and Quicktime), and in safe-mode.

With a fresh profile I browsed around until usage settled at about 213mb. Then repeatedly opened and closed a large number of tabs with www.gawker.com in them. ~10mins elapsed between closing a batchs of tabs and opening a new batch. Results were as follows for a fresh (default) profile (a few forums tabs remained open):

Mem Use after tabs closed, # of tabs opened then closed (in a batch):
213
251, 20
310, 40
322, 40
371, 50
403, 60
447, 70
466, 60
490, 70

Overall mem usage increased 277mb after opening/closing 410 tabs. i.e. an average increase of 0.68mb per tab.

This was repeated in safe-mode:

166
177, 10
220, 40
258, 40
314, 50

Overall mem usage increased 148mb after opening/closing 140 tabs. i.e. an average of 1.06mb per tab.

I think that an endurance test on opening and closing gawker.com tabs could be quite useful. Maybe do it about 3000 times to see if mem usage peaks or trends to an asymptote?
BTW, am on win7 64bit with 4GB of RAM. Am using a nightly build with this User Agent:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110323 Firefox/4.0b13pre

Build changeset:

http://hg.mozilla.org/mozilla-central/rev/774ec081a9c1
Sorry to add another comment, but memory usage is Private Working Set from Windows Task Manager.
I actually now suspect it might be Stylish at fault; taking it out seems to remove the acute perforamnce issues opening the gawker sites. I've got it deactivated and I'll see if there's still a slow memory leak, since a leak could have interacted with stylish's resource hogging. But after about an hour of browsing I'm still doing okay.
It's definitely not stylish, although stylish was causing serious problems for me on the Gawker sites (which is why I used them as the example). After a day of using Firefox with Stylish deactivated, memory usage with 3 tabs open was at 38%. Restarting and restoring those tabs brought me down to 6% (%s are out of 4GB). 

I'll run for another day in an empty testing profile to see if it recurs.
What other add-ons are you using? Are you using AdBlock Plus and no-script?
I've been using no-script but not adblock. Now I've switched over to a testing profile with no addons.
Tried on Win XP comp with 512MB of RAM, NoScript but no ADP - Fx was using 168,000 k before, after was 223,000 k. Seems it's not just a Mac bug.

Is it specific to these sites, though? I've seen other complaints of memory not all released - one was ZDNet, in their comparison test of the latest browsers (which was generally positive toward Fx 4.0).
Attached file about:memory data
I did tests opening 70 tabs of those gawker sites. Test build was: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110327 Firefox/4.2a1pre

Without ABP:
	firefox.exe	plugin-container
NEW SESSION	 23,508 	 -   
70 PAGES OPEN	 1,047,136 	 441,056 
PAGES CLOSED	 182,888 	 13,788 
		

With ABP:
	firefox.exe	plugin-container
		
NEW SESSION	 47,060 	 -   
70 PAGES OPEN	 1,036,324 	 169,908 
PAGES CLOSED	 741,472 	 9,680 

Memory is Window's Task Manager's "Private Working Set".

about:memory snapshots in the attachment, if those are useful.
What version of ABP were you using, and what filter sets?
I still have issues (maybe less?) when I run using only Noscript and Vimperator. 

I will be infinitely sad if these problems are vimperator's fault since vimperator is the only reason I use Firefox.
(In reply to comment #13)
> I still have issues (maybe less?) when I run using only Noscript and
> Vimperator. 
> 
> I will be infinitely sad if these problems are vimperator's fault since
> vimperator is the only reason I use Firefox.

Don't think that's likely. Many have memory issues without addons. I think some addons just exacerbate firefox's memory issues.
OK, I decided to do a marathon endurance test on opening and closing batches of 

100 or so gawker.com tabs (the new layout, not the version that uk.gawker.com may 

get).

This was performed on a fresh default profile with the latest nightly build 

(Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110327 

Firefox/4.2a1pre).One window remained constantly open holding a www.google.com 

tab, while a new window was opened and ~100x gawker tabs were opened in it, and 

after they all loaded it was closed. This process was repeated many times until 

3200 gawker.com tabs had been opened and closed in batches.

The memory use results from windows task manager were as follows:

#tabs_opened cumulative_#tabs Private Peak After Closing
10	10	229		
100	110	1397	1468	290
50	160	738	1468	312
50	210	765	1468	334
50	260	788	1468	328
50	310	761	1468	346
50	360	775	1468	354
50	410	790	1468	371
100	510	1386	1474	437
100	610	1399	1474	488
100	710	1397	1474	516
100	810	1384	1474	536
100	910	1390	1474	563
100	1010	1396	1493	577
100	1110	1384	1493	588
110	1220	1488	1608	602
100	1320	1403	1608	612
100	1420	1387	1608	615
100	1520	1391	1608	618
109	1629	1540	1619	643
100	1729	1398	1619	641
100	1829	1397	1619	639
100	1929	1430	1619	650
100	2029	1413	1619	649
110	2139	1504	1636	677
100	2239	1411	1636	668
100	2339	1413	1636	667
100	2439	1428	1636	669
100	2539	1422	1636	662
100	2639	1394	1636	666
100	2739	1399	1636	658
130	2869	1728	1830	661
131	3000	1768	1856	700
100	3100	1807	1963	724*
100	3200	1446	1963	718

* browser became quite unresponsive with dramatic leaking (~ 250mb in less than 

1min) on one page dramtically on one page before closing.

about:memory after closing 3000th tab:

    Overview

Memory mapped: 	1,569,718,272
Memory in use: 	348,639,830


    Other Information

Description 	Value
malloc/allocated	348,644,382
malloc/mapped	1,569,718,272
malloc/committed	741,761,024
malloc/dirty	3,960,832
win32/privatebytes	794,107,904
win32/workingset	796,819,456
js/gc-heap	192,937,984
js/string-data	3,360,558
js/mjit-code	9,391,888
storage/sqlite/pagecache	48,134,472
storage/sqlite/other	1,491,744
gfx/d2d/surfacecache	937,460
gfx/d2d/surfacevram	6,173,248
images/chrome/used/raw	0
images/chrome/used/uncompressed	514,500
images/chrome/unused/raw	0
images/chrome/unused/uncompressed	0
images/content/used/raw	71,440
images/content/used/uncompressed	401,112
images/content/unused/raw	0
images/content/unused/uncompressed	0
layout/all	730,074
layout/bidi	0
gfx/surface/image	1,030,112
gfx/surface/win32	0

about:memory after closing 3100th tab:

    Overview

Memory mapped: 	1,572,864,000
Memory in use: 	351,185,292


    Other Information

Description 	Value
malloc/allocated	351,189,844
malloc/mapped	1,572,864,000
malloc/committed	741,675,008
malloc/dirty	2,596,864
win32/privatebytes	817,500,160
win32/workingset	828,444,672
js/gc-heap	192,937,984
js/string-data	3,454,476
js/mjit-code	9,636,812
storage/sqlite/pagecache	48,167,240
storage/sqlite/other	1,491,744
gfx/d2d/surfacecache	940,404
gfx/d2d/surfacevram	6,173,248
images/chrome/used/raw	0
images/chrome/used/uncompressed	514,500
images/chrome/unused/raw	0
images/chrome/unused/uncompressed	0
images/content/used/raw	71,440
images/content/used/uncompressed	401,112
images/content/unused/raw	0
images/content/unused/uncompressed	0
layout/all	730,074
layout/bidi	0
gfx/surface/image	1,034,016
gfx/surface/win32	0

about:memory after closing 3200th tab:


    Overview

Memory mapped: 	1,566,572,544
Memory in use: 	348,598,224


    Other Information

Description 	Value
malloc/allocated	348,602,776
malloc/mapped	1,566,572,544
malloc/committed	736,677,888
malloc/dirty	3,493,888
win32/privatebytes	812,908,544
win32/workingset	824,389,632
js/gc-heap	188,743,680
js/string-data	3,484,902
js/mjit-code	9,888,849
storage/sqlite/pagecache	48,167,240
storage/sqlite/other	1,491,744
gfx/d2d/surfacecache	940,404
gfx/d2d/surfacevram	6,173,248
images/chrome/used/raw	0
images/chrome/used/uncompressed	514,500
images/chrome/unused/raw	0
images/chrome/unused/uncompressed	0
images/content/used/raw	71,440
images/content/used/uncompressed	401,112
images/content/unused/raw	0
images/content/unused/uncompressed	0
layout/all	731,101
layout/bidi	0
gfx/surface/image	1,034,016
gfx/surface/win32	0
(In reply to comment #12)
> What version of ABP were you using, and what filter sets?

1.3.5
EasyList
@Rodrigo: Could you try the latest development build of ABP? It seems to have fixed a bug causing a lot of memory not being released.
Indeed, it seems to be fixed. Same tests as Comment #11

Without Adblock Plus:

	firefox.exe	plugin-container.exe
NEW SESSION	23124	0
70 PAGES OPEN	1125552	647760
PAGES CLOSED	205012	19252


With Adblock Plus 1.3.6rc.2957:

	firefox.exe	plugin-container.exe
NEW SESSION	62260	0
70 PAGES OPEN	1061764	177268
PAGES CLOSED	257112	10152
Works for me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110406 Firefox/4.2a1pre

The memory and CPU processes are dropping as soon as I close the tabs.

Also, could you see if the issue occurs if using Firefox in safe mode:
http://support.mozilla.com/kb/Safe+Mode

How about with a new, empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile
This kind of bug often results in a pile-on, where multiple people report on similar symptoms and it all becomes very confusing.

So I've retitled this to be about the gawker problems John McDonnell originally reported.  John, can you summarize your findings so far with respect to the original problem?  It's hard to tell what the status is from the comments.  Thanks.
Summary: Memory leak: closing tabs does not deallocate memory. → Memory leak: closing gawker website tabs does not deallocate memory, add-ons may be involved
Hi, so I actually was having this problem in general, but the Gawker redesigned websites seemed to really strain the browser so I was using them as an example.

Lately I've been running with only:

- noscript
- vimperator
- rapportive- power twitter.

In my current configuration, after Firefox has been on for a day or two, it's using up about a quarter of my system's memory. I'm not doing anything "weird" besides running these plugins. I've also been steering clear of Gawker.

When I ran in a blank profile, the problem seemed less noticeable. 

I can try and run for a few more days with a blank profile to confirm that that fixes the problem if you think that would be helpful.
Reporter, do you have anything new to add about this issue?
I'll try to repeat the tests from comment 15 this weekend.
I have nothing new to report, but since I'm still having performance issues, I'll try running in a blank profile for a few days and see if I fail to replicate.
I think it must have been a plugin because I've been running in a blank profile for several days and have mostly been coasting between 14% and 18% memory usage. My prime suspect now is noscript.

As stated before, memory usage with plugins would soar up past 40%.
Reporter, considering comment25, can you please change the resolution of the bug to Resolved Worksforme or Invalid.
Okay, duly resolved.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
No longer blocks: mlk-fx5+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: