258567 - Firefox/Mozilla eat up memory on new-tab / new-window

Status: RESOLVED DUPLICATE of bug 131456

(Firefox :: Tabbed Browser, defect)

Description

[CM]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

I've noticed that Firefox doesn't realse memory which it reserves for new-tabs
or windows. You can reproduce it preatty easy:

Just keep pressing CTRL+T for some seconds. Close all the tabs which are open.
Wait and don't see the memory decrease. Hold CTRL+T again and see the memory
going up more. I can get the browser above 100mb very easy... 

Reproducible: Always
Steps to Reproduce:
1.CTRL+T for some seconds
2.close tabs
3.wait

Actual Results:  
memory increased and staid

Expected Results:  
release the memory

My System is a SuSE 9.0 machine. It has a P4 2.6GHZ and 1.2GB of memory.

Comment 1

[CM]

It seems that the browser stops doing when it reaches about 120mb (about 10% of
the actual isntalled memory). Right now I can open tabs and close them with no
change in the amount of memory it needs (VSZ, RSS). Is there maybe a limit to
which firefox increases memory and keeps it (regardless of usage)? If so, how
can I reduce it?

Comment 2

[saieditor]

Happens in Windows XP also, particularly with new (windows).. 

Comment 3

[Richard Schwarting]

True here as well, in Dropline Gnome on Slackware Linux 10, using 1.0 Preview
Release.

I wonder if it relates to
https://bugzilla.mozilla.org/show_bug.cgi?id=256424
which is concerned about memory hogged by Firefox after viewing images or
https://bugzilla.mozilla.org/show_bug.cgi?id=259713
which is more concerned about Firefox using crazy amounts of memory in Linux in
general.

Is there any information I can glean to help?

Comment 4

[Jason Knight]

Not so much eats memory, as it doesn't release all its memory when the tabs are
closed until the window is closed. You open up 20 large tabs in a row, close all
the tabs yet not close the window, not all the memory is released. Over and over
this leads to eventual failure of the program/system from being out of memory. I
have ONE firefox 1.0 window open right now, with no extra tabs open, and the
memory footprint for it is hovering around 300 megs - all from opening up a
bunch of tabs, then closing all the tabs...

Also, it seems that even less memory is released for closing a tab if you have
saves a link or image from the tab. A good gallery webpage can quickly overload
and crash the browser.

Comment 5

[timeless]

if you actually crash the browser using a mozilla.org build, then please
indicate the talkback incident id. if you insist on using a non mozilla.org
build, please insist on using one which has debugging symbols and provide a
stack trace (this is not an strace, see the debugging faq or irc for info about
providing one).

Comment 6

[metro_guy]

Thought I'd add another "me too" to this bug report. As it accurately describes
what I am seeing.

I am using Firefox 1.0 on Slackware Linux 10.0 (kernel 2.4.26) with 256MB of ram
Plugins: 
1) java plugin from java1.4.2_02
2) flashplayer7

I have noticed that Firefox does not release memory after tabs are
opened/closed.  Also, over a long period of time(2+hrs) with general surfing  it
starts to get really sluggish and also makes the system unstable by consuming
huge amounts of memory. 

I have tried modifying setting browser.cache.memory.capacity = 16-32MB but have
not seen any improvement.  Because of this I have stopped using  Firefox and
have reverted back to Netscape 7.1. which is a pig anyway, but at least it seems
to behave a little better. 

It could be the plugins I'm using and if that is true then FF is no use to me at
least until the next release. I will test this weekend without using any plugins.

MG

Comment 7

[matt235]

Happens in Windows 2000 as well.  This is a big leak, especially for low-RAM
systems.

Comment 8

[Jesper Krogh]

I'd just like to confirm this one. Opening 20 tabs and close them again usually
gives me 60+ MB of allocated memory (more than before). 

This usually sums up to a (very innoing) daily restart of firefox. 

This has been confirmed by quite a lot in this bug, any reason why this bug
isn't marked as CONFIRMED?

Comment 9

[Jason Knight]

@ [e-mail]
talkback incident id, debugging symbols, that would be all well and good if 
said mechanism WORKED when it locks up... When you end task and it won't end 
until you end task ALL the occurances, curiously leaving NO TRACE of any 
debugging or even a valid log file, that's kinda honkin pointless... under 
linux, it freezes X and sends it's own process into zombie-land.

Comment 10

[timeless]

then you didn't *crash*. a crash is a technical term. please don't use it when
you mean 'hang'. thank you.

Comment 11

[Jason Knight]

@ [e-mail]

You know, I've been using computers for thirty years and never had anybody make 
that distinction as a technical one, and to be honest with that attitude all I 
can say is good job on promoting Moz/FF. 

Of course the multiple examples of HOW TO recreate the error within a few 
minutes on any platform and still unconfirmed breeds real confidence in 
bugzilla and FF development as a whole. 

I think I'm done with Moz. as a whole. Good Job.

Comment 12

[timeless]

fwiw a developer has recently found at least one of the reasons that tabs cause
bad memory usage characteristics. note that i am not affiliated with firefox. i
scan bugs for reports about access violations by keyword. i can't do anything
quickly for hangs because there are no obvious stack traces and even if there is
a stack trace, it's probably for some complicated loop and not something simple
to analyze like deadlock.

Comment 13

[Robin Monks]

*** Bug 271201 has been marked as a duplicate of this bug. ***

Comment 14

[Robin Monks]

Dupe of bug 131456 (Comment #122).  Reporter, if you can reproduce on a newer
build, please REOPEN.

*** This bug has been marked as a duplicate of 131456 ***