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

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?

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 ...

*** 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.

(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.