Closed Bug 307018 Opened 19 years ago Closed 19 years ago

Opening and closing a tab leaks memory

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

(
URL
)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Windows Task Manager screenshot of excessive memory usage
(deleted), image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

If I open a new tab and close it, the memory does not seem to be released.  This
always happens.  Just ended up with firefox taking 92,000 kb memory with just
the mozilla home page open

Reproducible: Always

Steps to Reproduce:
1.Open tab
2.Load a page
3.Close new tab

Actual Results:  
Memory leak

Expected Results:  
Release the memory

Hasd tabbedbrowser extension intsalled, and then removed it - made no difference
This is WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050903 Firefox/1.6a1.  I'm guessing this is going to be something
specific to you.  Have you tried a clean install with a new profile?
Dupe of bug 283063?
Keywords: mlk
(In reply to comment #1)
> This is WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
> Gecko/20050903 Firefox/1.6a1.  I'm guessing this is going to be something
> specific to you.  Have you tried a clean install with a new profile?

Yep. Uninstalled Firefox, deleted profile, restarted with nothing but a fresh
download of 1.0.6.  Still leaks.
(In reply to comment #3)
> Yep. Uninstalled Firefox, deleted profile, restarted with nothing but a fresh
> download of 1.0.6.  Still leaks.

Does look like bug 283063 - this is patched an fixed on later builds than 1.0.6.
 Could you try a recent nightly build, to verify that the problem goes away - it
should if the dupe is correct.
(In reply to comment #4)
> (In reply to comment #3)
> > Yep. Uninstalled Firefox, deleted profile, restarted with nothing but a fresh
> > download of 1.0.6.  Still leaks.
> 
> Does look like bug 283063 - this is patched an fixed on later builds than 1.0.6.
>  Could you try a recent nightly build, to verify that the problem goes away - it
> should if the dupe is correct.

Tried last nights build an hour or so ago, and it performs just the same


Possibly a dupe of bug 280818 then.
After using firefox for a while, it accumulates memory.  I've had this problem both with Stable (1.0.7 and some versions before that) and the 1.5 Betas.

I've been on a Toshiba Tablet PC, running XP Tablet Ed.  (I didn't notice this problem on Linux).  I've had this problem on old installs as well as new.  Admittedly, previously it would take both a lot of memory and a lot of CPU.  It seems now only to be chewing memory.

This screenshot is from a brand new install, formatted yesterday, with an install downloaded yesterday.

As I write this, Firefox is creeping up again to 42MB...
Quick clarification.  When I said old installs it also chewed CPU, the most recent of those was 1.0.7.  I should also point out that I may not have been using the new Firefox beta long enough to incure a CPU chewing error.
http://primates.ximian.com/~federico/news-2005-11.html#moz-images
(In reply to comment #5)
> Tried last nights build an hour or so ago, and it performs just the same

Did you try it without extensions?

(In reply to comment #6)
> Possibly a dupe of bug 280818 then.

No, since that's suite only, and probably already fixed.

(In reply to comment #9)
> http://primates.ximian.com/~federico/news-2005-11.html#moz-images

That's about excessive **but not leaked** memory use.
Firefox 1.5 - the same trouble
(In reply to comment #11)
> Firefox 1.5 - the same trouble
> Indeed.  Just had 63,264K memory use with nothing but Google homepage open
(In reply to comment #12)
> (In reply to comment #11)
> > Firefox 1.5 - the same trouble
> > Indeed.  Just had 63,264K memory use with nothing but Google homepage open
> 

I can see the same problem with Firefox 1.5 and tabs.  Open a tab and memory ussage increases (as shown in Taskmanager).  That's logical.  However, closing the tab does not release the memory.  So, if you open enough tabs, the only way to get the memory back is to close Firefox.  Another workaround would be to NOT use tabs.  That's not a desirable solution.
This bug also occurs for me aswell in Firefox 1.5. I have tried it in safemode and the memory leak still occurs.
try this

http://forum.mozilla.ru/viewtopic.php?pid=71019#p71019

on Russian
Note that the latest version of Adblock (not Adblock Plus) contains a serious memory leak in Firefox 1.5.
By setting config.trim_on_minimize to true in about:config releases the memory when you minimize the Firefox window to the taskbar which gets around the memory leak without restarting. Still doesn't fix the problem.

Jo Hermans: This leak occurs when you don't have any extensions or themes installed aswell.
Does trim_on_minimize make it need to reload the pages after you restore it?  Does it have any other negative (or other) effects?

If not, why not just make that the default behavior?

Of course, it would probably be a good idea to fix the bug itself...

Also, I think someone needs to confirm this.  I'd do it myself, but I'm not ranked high enough or something.
(In reply to comment #18)
> Does trim_on_minimize make it need to reload the pages after you restore it? 
> Does it have any other negative (or other) effects?
> 
> If not, why not just make that the default behavior?
> 
> Of course, it would probably be a good idea to fix the bug itself...
> 
> Also, I think someone needs to confirm this.  I'd do it myself, but I'm not
> ranked high enough or something.
> 


It doesn't apear to have any negative effects and doesn't need to reload the pages. When I looked up the pref. at http://kb.mozillazine.org/Config.trim_on_minimize#Related_bugs it said it was disabled by default to keep the app responsive.
Hey!  A solution that works!  Thanks

(In reply to comment #19)
> (In reply to comment #18)
> > Does trim_on_minimize make it need to reload the pages after you restore it? 
> > Does it have any other negative (or other) effects?
> > 
> > If not, why not just make that the default behavior?
> > 
> > Of course, it would probably be a good idea to fix the bug itself...
> > 
> > Also, I think someone needs to confirm this.  I'd do it myself, but I'm not
> > ranked high enough or something.
> > 
> 
> 
> It doesn't apear to have any negative effects and doesn't need to reload the
> pages. When I looked up the pref. at
> http://kb.mozillazine.org/Config.trim_on_minimize#Related_bugs it said it was
> disabled by default to keep the app responsive.
> 


(In reply to comment #0)
> 1.Open tab
> 2.Load a page
> 3.Close new tab

What is the page in step #2? How are you opening the page (e.g. typing it in the URL bar, going to a bookmark, etc.)? Is it the same page every time? Depending on what page is opened, you could be seeing any number of memory leaks associated with loading that page, or not see any memory leak at all.
(In reply to comment #21)
> (In reply to comment #0)
> > 1.Open tab
> > 2.Load a page
> > 3.Close new tab
> 
> What is the page in step #2? How are you opening the page (e.g. typing it in
> the URL bar, going to a bookmark, etc.)? Is it the same page every time?
> Depending on what page is opened, you could be seeing any number of memory
> leaks associated with loading that page, or not see any memory leak at all.
> 

Any URL at all, of any kind, entered in any way I can imagine
I couldn't reproduce any kind of "memory leak" with the original steps to reproduce, but I can sometimes (about 10-20% of the time) get a memory leak with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060120 Firefox/1.6a1 using a new profile following these steps:

1. Open Firefox
2. Click on the URL bar and press the Enter key to put the URL of the home page in the URL bar history
3. Type Ctrl+T to open a new tab
4. Right-click in empty space in the tab bar (not on a tab) and select New Tab from the context menu
5. Select the start page from the URL bar dropdown menu
6. Close the two tabs you opened by clicking on the X in the tab bar
7. Close Firefox

Usually, leak gauge shows that nothing leaked. Sometimes, however, I get this huge report:

Leaked outer window 17fbc00 at address 17fbc00.
Leaked inner window 118d490 (outer 17fbc00) at address 118d490.
 ... with URI "about:blank".
Leaked outer window 186f720 at address 186f720.
Leaked inner window 1f14500 (outer 186f720) at address 1f14500.
 ... with URI "chrome://browser/content/browser.xul".
Leaked outer window 207b6b8 at address 207b6b8.
Leaked inner window 2197200 (outer 207b6b8) at address 2197200.
 ... with URI "http://www.mozilla.org/projects/deerpark/alpha2.html".
Leaked document at address 176e0d0.
Leaked document at address 17fa9e8.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/popup.xml".
 ... with URI "chrome://global/content/bindings/popup.xml".
Leaked document at address 1fbebc0.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/text.xml".
 ... with URI "chrome://global/content/bindings/text.xml".
Leaked document at address 18a0710.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/general.xml".
 ... with URI "chrome://global/content/bindings/general.xml".
Leaked document at address 186b058.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/stringbundle.xml".
 ... with URI "chrome://global/content/bindings/stringbundle.xml".
Leaked document at address 1fce008.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/autocomplete.xml".
 ... with URI "chrome://global/content/bindings/autocomplete.xml".
Leaked document at address 17c62a0.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/tree.xml".
 ... with URI "chrome://global/content/bindings/tree.xml".
Leaked document at address 1f24f90.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/toolbar.xml".
 ... with URI "chrome://global/content/bindings/toolbar.xml".
Leaked document at address 1fdbe30.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/menu.xml".
 ... with URI "chrome://global/content/bindings/menu.xml".
Leaked document at address 1ff9610.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/splitter.xml".
 ... with URI "chrome://global/content/bindings/splitter.xml".
Leaked document at address 1ff7818.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/tabbrowser.xml".
 ... with URI "chrome://global/content/bindings/tabbrowser.xml".
Leaked document at address 20045c0.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/tabbox.xml".
 ... with URI "chrome://global/content/bindings/tabbox.xml".
Leaked document at address 20554d0.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/toolbarbutton.xml".
 ... with URI "chrome://global/content/bindings/toolbarbutton.xml".
Leaked document at address 2036d60.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/button.xml".
 ... with URI "chrome://global/content/bindings/button.xml".
Leaked document at address 2061c68.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/browser.xml".
 ... with URI "chrome://global/content/bindings/browser.xml".
Leaked document at address 2013458.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/progressmeter.xml".
 ... with URI "chrome://global/content/bindings/progressmeter.xml".
Leaked document at address 2054c28.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/textbox.xml".
 ... with URI "chrome://global/content/bindings/textbox.xml".
Leaked document at address 20bf3e8.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/platformHTMLBindings.xml".
 ... with URI "chrome://global/content/platformHTMLBindings.xml".
Leaked document at address 1fd2e08.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/browser.jar!/content/browser/search.xml".
 ... with URI "chrome://browser/content/search.xml".
Leaked document at address 1f2c300.
 ... with URI "http://www.mozilla.org/projects/deerpark/alpha2.html".
Leaked document at address 20c4690.
 ... with URI "jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/bindings/scrollbox.xml".
 ... with URI "chrome://global/content/bindings/scrollbox.xml".

Summary:
Leaked 6 out of 16 DOM Windows
Leaked 21 out of 34 documents
Leaked 0 out of 5 docshells
(In reply to comment #22)
> Any URL at all, of any kind, entered in any way I can imagine

I'm closing this as WFM. I'll demonstrate that when a tab is closed, the memory is released:

Steps to reproduce:
1. Start browser.
2. View Mem Usage and VM Size.
3. Open a new tab.
4. Go to URL http://www.gnu.org/software/libc/manual/html_mono/libc.html
5. View Mem Usage and VM Size.
6. Close the tab.
7. View Mem Usage and VM Size.

Here are the results for three different Windows browsers (Mem Usage, VM Size)
                     At step 2      At step 5      At step 7
Firefox 1.5.0.1      (19MB, 10MB)   (74MB, 65MB)   (25MB, 16MB)
Opera 9 Preview 2    (20MB, 17MB)   (70MB, 67MB)   (22MB, 19MB)
IE 6 SP 2            (31MB, 17MB)   (61MB, 46MB)   (34MB, 18MB)

I opened a new window instead of a new tab in IE because it doesn't have tabs. As you can see, all browsers (including Firefox) free most of the extra memory the tab used, but don't free all of it.

Feel free to open a new bug report about what I found in comment #23 if you like. It does demontrate that in some situations opening and closing a tab might leak memory.
URL: http://www.gnu.org/software/libc/manu...
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Steven, your test was fine, except for the most critical detail: the webpage you visited had not a single image on it.  (2MB of pure text was quite impressive though.)

Now I thought I read a small study that it was an image related thing on this bug-thread, but realized (after re-reading all the posts) that it must've been somewhere else.

So, I offer you an alternate test.  Close Firefox entirely.  Open a new instance of Firefox.  Check the memory.  Now head over to http://www.deviantart.com, and browse around the art there, whatever your favorite style is (as long as its an image, not flash or something).  Make sure you open the full-views.  After a bit of really intensive surfing (say an hour, if you really want to guaruntee results), and check the memory again.  Obviously, less time spent = less images seen = less obvious results.  I've also uploaded a 10mg jpg to http://www.voidfx.net/scraps/Cliff_for_Steven.bmp to get you started, though I don't think just reloading it over and over will help, cause it might just call the cache.

I'm on the latest stable (Firefox/1.5.0.1), and I just tested it out myself, and its still happening.
(In reply to comment #25)
> Steven, your test was fine, except for the most critical detail: the webpage
> you visited had not a single image on it.

The bug in this report is about Firefox leaking memory when a tab is opened and closed *with any page* opened in the tab. If you see a bug about a memory problem *with a particular kind of page*, that would be a different bug and needs a separate bug report. Feel free to report it, and if we can reproduce the problem, we'll confirm the bug.
Bug 327418 is about a problem with memory not being released when tabs are closed. I can't reproduce it, but maybe that's a problem some of you here are having.
(In reply to comment #27)
> Bug 327418 is about a problem with memory not being released when tabs are
> closed. I can't reproduce it, but maybe that's a problem some of you here are
> having.
> 

When I said "any page" I did mean it - including plain html with no images, javascript, flash or other complications.  
The trim_on_minimize setting DOES clear the memory - is there really any downside in making this default?
(In reply to comment #28)
> The trim_on_minimize setting DOES clear the memory - is there really any
> downside in making this default?

This is a common misconception. It *doesn't* clear memory -- it swaps memory out to disk, which is why it makes the Mem Usage go down. The downside is that Firefox becomes slower as it moves the memory from disk back into RAM.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: