User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 I've noticed this since 1.2. As you browse pages and such, opening new windows or tabs or both and closing them, Mozilla's memory usage according to Task Manager, (for obvious reasons) increases but even after closing all but one window and one tab with the blank page, the memory usage does not decrease. (I've personally had it balloon over 200MB) It takes a while to actually quit (takes about two or so Ctrl-Q tries to do it). Then I restart Mozilla to start the cycle over again. It's as if the "garbage collector" is on strike (sorry, java talk....). Reproducible: Always Steps to Reproduce: 1. Browse some websites 2. Browse some more websites 3. Browse even more websites 4. Repeat 1-3 for a while. 5. Open new blank tab and close all other tabs. 6. Notice that the memory usage doesn't go down. 7. Go to Starbucks to grab some coffee/mocha/latte/whatever. 8. Repeat if necessary. Actual Results: Mozilla's memory usage balloons up and doesn't go down and you get your caffeine fix. Expected Results: Memory usage should've gone down. (Caffeine fix stays)

Please look at bugs 198806 and 213391. They are both related to memory usage and, as they are image-related, fixing them would surely make the memory leaks less evident.

yea....it might be an image-related issue but from my experience, it can also happen even if image loading is turned off....it just takes FOREVER to get to that point.

Since it seems to depend on all kind of different bugs (where memory just is not properly released to the OS), that are all factors to the permanent memory increase and the description of this bug is not very specific (just the results are here, the reasons for it can be found in the depending bugs), I suggest making this one a meta bug for tracking the strange memory increase.

only drivers can set blocking flags and you shouldn't set the priority on a bug you don't own. and why do we need a tracking bug? what's wrong with searching for bloat and mlk keywords? not enough spam?

Well.. this bug still exists, and I think this is one of the most serious bug. Doesn't mozilla code free memory after it allocated a dynamic memory?

Seems to be same problme as Bug 212197 ( memory balloons to over 200MB )

Unreleased virtual memory on window close is one of the causes of this problem. Problem recreation scenario: (1) Start "Task Manager" of MS Windows 2000(or XP) and choose "process". Display "Memory Usage"(probably real memory) and "Virtual Memory Size". (2) Start Mozilla ("Image Name" is mozilla.exe) (Home Page setting : http://www.mozilla.org/start) (3) Repeat "Open New Tab" and "Close Tab" -> "Virtual Momory Size" increases on tab open and decreases on tab close No problem. (4) Repeat "File/New/Navigatio Window"(CTRL+N) and close opened window -> "Virtual Momory Size" increases on open but doesn't decrease on close This is the problem. (5) Repeat step(4) again and again. Virtual storage increases constantly. (6) Minimizing of window reduces "Memory Usage(probably used real memory)" to several Mega Bytes order. "Memory Usage" after re-activation is smaller than one before minimize. This indicates Real Momory is freed successufully. If URL of new windows is page contains large data such as image, increment of virtual memory size in step (4) becomes very large. Following is test result with 2004042808-trunk on Win-2K(SP4), Cerelon 500MHz, 128MB memory, HDD 10GB, Swap is set 256MB. (0) Set HOME page to file://C|/test/testdata.bmp testdata.bmp is Bit Map file of 3MB. (1) Start Mozilla Browser => Virtual Memory Size = 20MB (2-1) Open 10 new browser windows by CTRL+N => 64MB (2-2) Close opened 10 browser windows => 62MB (3-1) Open 10 new browser windows by CTRL+N => 95MB (3-2) Close opened 10 browser windows => 92MB (4-1) Open 10 new browser windows by CTRL+N => 124MB (4-2) Close opened 10 browser windows => 122MB (5-1) Open 10 new browser windows by CTRL+N => 154MB (5-2) Close opened 10 browser windows => 152MB (6-1) Open 10 new browser windows by CTRL+N => 183MB (6-2) Close opened 10 browser windows => 181MB (7-1) Open 10 new browser windows by CTRL+N => 217MB (7-2) Close opened 10 browser windows => 213MB (Stopped test because Swap area was expanded) (8-1) Memory Usage(real momery) was 60MB at this step. (8-2) Minimize Browser Window => Memory Usage(real momery) bocomes 2.8MB (8-3) Re-activate Browser Window => Memory Usage(real momery) bocomes 12MB Virtual memory is aparantly not released on window close. 2 to 4 MB reduction of virtual memory size on each 10 window close is probably result of successuful release of 3MB of BMP data.

Testcase is in previous comment. Why is "invalid" on status whiteboard?

I've found that phenomenon of Comment #7 observed when extention of "Tab Browser Extentios(TBE)" is installed. When uninstalled TBE, pure Mozilla trunk since no other extentions, infinite virtual storage increase did not occur on repetive window open/close. I do not know whether cause is TBE's fault only, or cause is Mozilla's lack of resource clean up function of resource for extentions, or both. In addition, a Japanese user also reported at Bugzilla.jp that he experienced virual memory increase phenomena with extention of "Auto Scroll". To all problem reporters : Do you use some extentions? Or use pure Mozilla?

Creater of TBE and I have found that large virual storage on window open/close descrived in Comment #7 is TBE's fault - extention did not destory objects created by TBE on window close. And test version of TBE resolved problem of Comment #7, although this fix is not available yet. Please note that current TBE does not have this type of problem on tab open/close. In additon, Japanese user reported virual storage increase problem when another extention is used, TBE is not used, as I mentioned before. So some extentions fault can be one of the casuse of this bug since programer, like me, tends to forget to free memory(destroy object in JavaScrit) which should usulay be done on tab close or window close. Again, do you use extentions? If yes, remove extention and try pure Mozilla. Too large virtual storage problem will occur on pure Mozilla?

> Testcase is in previous comment. apparently it wasn't... > Why is "invalid" on status whiteboard? when I put in INVALID there (comment 4), this bug had no specific steps to reproduce and the best suggestion at that point was to turn this into a tracking bug, which is not useful since there are already keywords for this purpose. General memory increases like this can be caused by bug 130157.

For problem of Comment #7, new version of TBE(2004-05-09 version) has been released at TBE owner's site, to which object destroy logic on window close is added.

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