Closed Bug 174604 Opened 22 years ago Closed 18 years ago

Mozilla not releasing memory

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: c.hamacher, Assigned: jst)

References

(
URL
)

Details

(Keywords: memory-footprint, memory-leak) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021010
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021010 and Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021007

The DOM application at the above URL is leaking memory: the memory used while
drawing the boxes is not returned - neither when pressing 'clear', nor when
leaving the page or even destroying the tab the application was launched in.

(all memory values according to Win taskmanager, but 'Size' - not RSS! - of top
under Linux yields analogous results)

Reproducible: Always

Steps to Reproduce:
o start a fresh Mozilla, and open some tabs
   (KDE, Mozilla, Mozillazine and Heise Newsticker)
        24,7 MB
o open MailNews, and open Adrian's original Message
        33 MB
o click link in Adrian's post, so that Mozilla page gets replaced
        33 MB
o start app
        33,6 MB
o draw 1000 boxes
        52,5 MB
o drag boxes around
        52,5 MB
o press "clear all"
        51,5 MB
o again draw 1000 boxes
        56 MB
o again delete boxes
        55 MB
o yet again create 1000 boxes
        58,3 MB
o yet again delete them
        57,3 MB
o go back to Mozilla page
        55,6 MB
o destroy tab
        55,5 MB
Actual Results:  
As you can see in the above steps to reproduce, the memory used by Mozilla
continuously increases, and is not released upon closing of the tab/window the
application is launched in

Expected Results:  
Memory should be returned, either when clearing the boxes, or at least when the
tab/window is closed
added keyword 'footprint', CC -> cathleen, rjesup (both as per rjesup's comment
in thread 'DOM performance' in n.p.m.p), reassigned to jst@netscape.com, also as
per rjesup's suggestion
Assignee: asa → jst
Keywords: footprint
Out of curiousity... If you do all that, close the window, then go back to that
page and repeat steps 

o draw 1000 boxes
o drag boxes around
o press "clear all"
o again draw 1000 boxes
o again delete boxes
o yet again create 1000 boxes

what happens?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Re: comment #2

(Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021013)

Hmm, this looks interesting. I retraced the the steps originally reported, did
some more iterations of creating and deleting the boxes in order to confirm that
the memory consumption is not tapering off, then killed the tab, opened a new
tab, went to the test site again, and again iterated creating and deleting boxes.

These are the results in MB according to task manager:

after create: 46,3 49,0 51,0 52,7 54,2 55,9 57,5 59,2 60,8
after delete: 45,9 48,3 50,2 52,0 53,5 55,2 56,8 58,5 60,0

Kill tab: 55,3
new tab & page: 55,3

after create: 56,9 57,6 58,0 58,6 59,0 59,5 60,1 60,5 61,9 63,2 64,9 66,6
after delete: 56,3 56,8 57,3 57,8 58,2 58,8 59,3 59,8 61,2 62,5 64,2 65,9

Kill tab: 59,5

Summarizing: 
In the first stage of the create/clear iterations, each creation of the 1000
boxes consumes 2,4MB of memory, of which 0,7MB are returned after clearing the
boxes. 
Killing the tab after the last clear returns part of the lost memory, but not all.
In the second cycle of create/clear iterations, the amount of additional memory
needed for the creation of the 1000 boxes is smaller: each time, 1.25MB are
consumed, of which again 0,7MB are freed after the clear. This reduced
consumption of additional memory for each create continues until the size of the
process at the end of the first iteration is reached (approx. 60MB). From then
on, again about 2,4MB of mem are used for each new create, of which 0,7MB are
returned after the clear.

To my eyes, this looks like part of the memory 'lost' in the first cycle is 
reclaimed during the second cycle. However, there still seems to be the problem
that the process will grow beyond all limits if the iteration is continued long
enough.

Tonight, when I'm back at my linux machine, I will try the same there.

  -Chris

Ah, OK.  So this is _partially_ bug 130157, most likely. It's still odd to me
that  deleting the divs and then recreating them will not just reuse the memory
from the old divs; I'll try to take a look at that when I get the chance to.
Updating component ...
Component: Browser-General → Layout
Depends on: 130157
Blocks: 92580
Hardware: PC → All
Keywords: mlk
QA Contact: asa
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1?
*** Bug 278111 has been marked as a duplicate of this bug. ***
*** Bug 308572 has been marked as a duplicate of this bug. ***
Minimizing FireFox releases memory (ditto with Thunderbird).
(In reply to comment #8)
> Minimizing FireFox releases memory (ditto with Thunderbird).
> 
Some people see that, I don't. Here Firefox's memory use increases slowly but surely over time, and AFAICT the only way to release it is to close the browser completely (e.g., with File -> Exit).

I'm currently using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051112 Firefox/1.5", build ID:2005111203 (where I just checked that minimizing releases nothing); and I'm not ready to switch to an alpha build.
I think this bug is _partialy_ Bug 131456 which was resolved by finding/resolving Firefox Bug 283063.

(In reply to comment #8)
> Minimizing FireFox releases memory.
(In reply to comment #9)
> Some people see that, I don't. 

If your OS is MS Win, read thru Bug 76831, very very tough work though, for difference of MS Win's behaviour when config.trim_on_minimize=true and when config.trim_on_minimize=false.
config.trim_on_minimize=false is already defaulted on trunk by Bug 76831 Comment #441.
(In reply to comment #3)
> To my eyes, this looks like part of the memory 'lost' in the first cycle is 
> reclaimed during the second cycle. However, there still seems to be the 
> problem that the process will grow beyond all limits if the iteration is 
> continued long enough.

With Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060721 Minefield/3.0a1 I could not get memory use to go above 47 MB. I tried drawing 1000 boxes twenty times, and the last ten times memory use went up after drawing the boxes and back down again after clearing the boxes.

Is there any set of steps that will cause the browser to keep eating more and more memory without limit? If so, please give the precise steps (including which numbers to enter, which buttons to press, and where to move the mouse) and your browser and OS versions.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
(In reply to comment #11)
> (In reply to comment #3)

Wow what speed of reaction ! 
I don't know if the author of comment 3 is still alive since 2002-10-16
perhaps youv've been sleeping for 4 years...
Furthermore, if I don't mistake Minefield/3.0a1 is an unstable release of FIREFOX
while the bug was about mozilla... you shoul go back to sleep
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #3)
> 
> Wow what speed of reaction ! 
> I don't know if the author of comment 3 is still alive since 2002-10-16
> perhaps youv've been sleeping for 4 years...
> Furthermore, if I don't mistake Minefield/3.0a1 is an unstable release of
> FIREFOX
> while the bug was about mozilla... you shoul go back to sleep
> 

If I'm not mistaken, this bug is labeled "Core", not "Mozilla Suite" in the Product field. Core bugs are common to all products.
You need to log in before you can comment on or make changes to this bug.