build 2001080303, Modern theme, Win2000/Win98. Measured with SpyGuru or Task Manager: Case 1. Start browser. Open a new window (home page set to blank) and close it. Repeat 10 times. Memory occupied by Mozilla will be increased by 1.2MB Case 2. Start browser. Open a new window (home page set to blank). Subsequently open 10 new windows, then close them. Mozilla memory usage will be increased by 3.8-4MB ! There was already a bug about memory leak after closing windows but it is resolved as fixed.

I don't see this. I repeated your steps with the added step of minimizing the remaining window and then looked at memory usage. I don't think we're leaking the 4 MB you claim.

Are you using Win32 OS ? Anyway, in order to clear up some things and to show how this bug (if valid) affects turbo mode, I modified my test case. Initial conditions: - For Win2000, I installed from scratch in Win2000 (uninstalled previous version, erased $home and Mozill.org directories) and created a new profile. Sidebar & personal toolbar disabled, skin=Modern, home=blank. Build 2001080303. For measuring memory occupied by Mozilla, I used Task Manager and SpyGuru. - for Win98SE, I uninstalled previous version and installed the new one, keeping my normal profile. I created a test profile (no migration) with the default settings. Sidebar & personal toolbar disabled, skin=Modern, home=blank. Build 2001080408. For measuring memory occupied by Mozilla, I used SpyGuru and AnotherTaskMan. Test case: 1. run "mozilla -turbo". Measure occupied memory. 2. run mozilla and press Ctrl+N nine times (10 visible maximized windows). No other interaction with the browser. 3. close all visible windows (using "x" button). Measure occupied memory. Results: Win2K: UTIL STEP1 STEP3 STEP3-STEP1 Win Task Man. 16100 20016 3916 KB SpyGuru 8462 12275 3813 KB Win98SE: UTIL STEP1 STEP3 STEP3-STEP1 SpyGuru 20664 26832 6168 KB AnotherTaskMan 34316 41416 7100 KB NOTE: No profile manager invocation. I'm not absolutely sure about the validity of the measurement method I used because, beyond other issues, different memory monitors give different absolute results. But the memory differential is similar. Perhaps there might be a serious flaw in my concept of measuring memory usage, yet I still think we have a serious problem here. I 'll try to make further investigation using different tools.

adding a few folks that know more about this that I do.

dave, can you add this test?

I am seeing this on windows 2000 as well. I opened mozilla (no turbo mode) and it was at about 19.5 megs. I opened 10 windows and then closed all the new ones and mozilla is now taking up 26.8 megs (using task manager). I have noticed this for a while -- thought it was a known bug.

->dprice

Marking as new. I was able to see about a 4 megs of growth after opening and closing 10 new windows. I checked about:bloat with one window open, and it showed 2.3 megs of un-released memory. With 10 windows open, that grew to 9.3 megs. After closing back down to one window, about:bloat once again showed 2.3 megs of un-released memory. Upon exiting, the total leakage for the session was only 2.3K Next I ran the tests with purify. I was unable to find a signifigant leak at the end of the session. Long story short... I see this too, don't quite know how to approach it.

Are we sure this isn't just the image cache (memory cache) filling up? (I once observed (I think) the same image being put into the image cache multiple times by putting a printf / stack walk in nsImageGTK::~nsImageGTK and nsImageGTK::Init, but Pavlov denied it.)

I did testing with the default page set to about:blank and the sidebar disabled. If it is the image cache filling up, it is filling with stuff from the chrome. But I agree, it could very well be a side effect of some cache growing.

Looks similar to Bugzilla Bug 39238 ... DUPs ?

No.

Anyone think this could get into 0.9.4?

-> cathleen for a new home

If the browser actually loads a page, then the leak is much higher In this example I have set the home page to www.mozillazine.org. start -turbo (no windows) = 13.488 kb Open 1. window = 22.332 kb Open 2. Window = 24.720 kb Open 10. Window = 43.760 kb Close all windows = 28.080 Kb total leak 28,080-13,488 = 14.592kb This is just with one page, if i do it with different pages the leak is even higher nominating for mozilla 0.9.5

add CC

I don't consider this a leak. If another windows app needs the memory it takes it. I believe this is just another case of windows not reporting the state of memory well. Try minimizing the open browser window, maximize it and look at the numbers again. I

to test if this is an artifact of the memory cache filling can some one try setting memory cache size to zero? we should try and figure out where that memory is really going. we should run this test milestone to milestone, and maybe daily to track progress. is there any programatic way to hook this into any of our automation? can someone try this on 0.9.2 and 0.9.3? I think about:bloat will get us the best numbers, but that might work only in debug builds.

Asa Dotzler : SpyGuru reports VM, not "physical" memory so it's measurements should not be affected by minimising windows (to be sure I did what you suggested and indeed there wasn't even the smallest change in footprint). Task Manager reports similar results, if I set it to monitor VM used. Chris Hoffman : I do not suggest setting Mozilla memory cache to zero since this resulted to Mozilla being unable to pass after the splash screen (build 2001083103, on Win2k). I needed to edit prefs.js to recover. But after setting it to as small as 10 KB, it worked. But SpyGuru keeps reporting the same virtual memory occupied by Mozilla (isn't it curious ?) and memory leak (or whatever) is also not affected at all. I would like to try about:bloat but nightlies are not debug builds, right? Where I can obtain one ? (I am not able to build one for myself because of lack of compiler and disk space).

trace-malloc (available only in builds compiled with it) will probably get much better numbers than about:bloat, since about:bloat only tracks certain logged objects

Does the same thing happen if you do {open a second window, and then close it} ten times? If not, that means Mozilla is keeping structures from the 10 extra windows around in order to re-use them when you open a new window again, and this isn't a memory leak bug.

With about:blank set as my homepage: Start Mozilla: 17988 k After opening a second browser window and closing it 10 times (leaving me with only one window open) 22704 k. *Note* no webpage loaded at all. with mozilla.org set as my homepage: Start Mozilla: 19892 k After the 10 windows as above: 24678 k ------------------------------- With about:blank set as my homepage: Start Mozilla: 19872 k After opening 10 browsers windows all at once, then close all ten: 30180 k With mozilla.org set as my homepage: Start Mozilla: 19872 k Open same as above: 33692 k

It looks like we are leaking 4 megs of memory here even on the best case..... Thats really alot -- could anyone nominate this for mozilla 0.9.6 for me?

see http://www.mozilla.org/performance/tools.html for some performance measuerment tools.

this really should be fixed soon. IMO it is the last thing that still makes mozilla a class b browser and - from a d*mb user's perspective - no better than netscape4 (ducking for cover! ;->). i have to restart mozilla every few hours or it will crash on the next best page load. i have lost hours of time because of this bug. having finally found a couple of web pages with valuable information, then the browser crashes and you start searchnig from scratch. my bookmarks file is completely bloated with bs* because every time i found something that might be useful i bookmarked it out of fear mozilla might say bye-bye too soon. some more tests: System: K7 700MHz, 256MB RAM Windows 2000 Mozilla 0.9.5 (build 2001101117) Memory used after start (no page loaded) 19.000 KB Memory used after opening 10 windows (blank), then closing them again. 30.804 KB ---> all without even looking at 1 line of html. if you browse normally, the memory 'loss' is far worse. when mozilla finally crashes the memory usage typically is around 60-70 MB. by then, the 'stop' button starts to occasionally disappear ... a sure sign to restart. there are many other bugs that describe similar problems, there might be some dups. maybe someone with more insight into bugzilla can check for dependencies/dups. 49141 new window performance 78077 Window opening times get really slow after opening multiple browser windows (on win32) 107371 New browser windows take up to 6 seconds to open on an Athlon 1.2Ghz! 105998 Browser does not open new windows 68002 Window.open() in javascript should be faster (the following contains links to some more technical bugs that might help) 94661 Mozilla unresponsive when loading multiple windows ... this is also a cross-platform bug, people on Mac,Win32,Linux,Solaris,0S/2... all see similar probs. i think this is a major problem that keeps many users from browsing with mozilla. especially experienced surfers that a) can offer valuable debugging help and b) will recommend mozilla to other users if they like the browser themselves. phil

Phillip, the problem with this bug is finding out the exact cause of the memory "expansion". Finally it seems to me more of a footprint than a leak issue, yet so far I have failed to find a suitable tool for investigating it further (Purify demo always crashes on my Win2k/SR2 system when loading Mozilla). Let's hope someone with sufficient knowledge of Mozilla and perf tools will take a look at this soon. As for the bugs you referred, probably they are not related with this one.

->cathleen

Note: some of the things reported by VM sizes are misleading. Part of the issue is fragmentation and the memory allocator. Part of it is caches of various types filling up. Opening and then closing windows will NOT generally return all the memory used to the system, at least not right after startup. The real test is to document the amount of memory "lost" between window open/close numbers N and N+1, where N is a largish number. That's not to say we aren't leaking anything, however the pageload leak tests (last I looked) showed little if any leaking after all the caches filled and fragmentation stabilized. I know that some of the worst window open/close leaks (1+MB/window even after a large number of opens closes) were solved a few months ago (I forget the bug number, but check for resolved/verified bugs I reported with mlk keywords).

I have been having this problem on Windows 2000 as well. Currently, with 9 windows open (nothing complicated - 2 Yahoo news, 2 Hotmail & 5 Bugzilla), my memory usage is 91.708 megs!!!!! (from Windows 2000 task manager) Mozilla has been running since yesterday. My memory usage creeps up non stop, and I have to restart every day or so. I've come into work, and found "out of memory" errors on my screen, and Mozilla eating 160+ MB!!!! Closing 5 windows (leaving Yahoo, Hotmail, 2 bugzilla), my memory is *STILL* 91.4 MB This is completely reproducable -- it happens every day or so. Memory usage goes up, but never goes down more than a couple of hundred KB. I am currently using 0.9.5, and it also happened with 0.9.4 (the first Mozilla I used). I switched to Mozilla because my new PC at work with Win2K kept locking up after 3-5 minutes running Netscape 6.1.

On restarting Mozilla, loading the Google page only, memory usage is 20 MB. Had this bookmarked, loading this page went to 22 MB. Launched 10 new browser windows (all Google), now 37 MB. Closed all new browsers (leaving just this), now 36.36 This is a 95% memory "leak". During my normal browsing (like reading news), I open each story in a new window, read it, and close that window (so I don't have to reload the page I was on & scroll down to where I was). Thus, I get hit hard by the memory leak.

Glen: Please try opening 10 google windows, closing them (record VM usage), open 10 more, close them (record VM usage). Compare the two. If VM used increased significantly, open and close 10 more windows and compare. Remember that most programs don't return all the memory they use to the OS just because you close a window. They may free() it, but it's still marked by the OS as allocated to the process - it's in malloc's free heap usually. The question is whether usage continues to climb after the memory heap reaches steady-state, or are there real leaks. Additional information needed: What version of mozilla are you running? What skin/theme? When was your profile created? Any non-standard options in use in prefs? What's the result from the above memory tests? OS version and patch level. Thanks

Glen, please read my previous response to your comments in this bug. Thanks.

Randell- here is the memory usage (KB) for opening Google windows: initial load: 20,900 10 more windows: 37,304 Close 10 new: 36,472 Open 10 again: 41,264 (note, as I started opening, mem first went DOWN to ~35, then crept up) Close 10: (forgot to check) open 10: 45,300 close 10: 45,092 Open 10 (yet again): (went down to 44.8 after opening first, broke even on 5th) 49,428 **note, response time to open each new window is getting sluggish** Close 10: 49,288 Open 10: 55,108 (getting quite sluggish ~2 seconds to open browser) Close 10: 54,876 System Info: ------------Browser: Mozilla 0.9.5 (2001101117), Modern Theme Profile: created 9/14/2001 -- under Netscape 6.1 Prefs additions: *user_pref("capability.policy.default.Window.innerHeight.set", "noAccess"); *user_pref("capability.policy.default.Window.innerWidth.set", "noAccess"); *user_pref("capability.policy.default.Window.outerHeight.set", "noAccess"); *user_pref("capability.policy.default.Window.outerWidth.set", "noAccess"); *user_pref("capability.policy.default.Window.resizeBy", "noAccess"); *user_pref("capability.policy.default.Window.resizeTo", "noAccess"); *user_pref("capability.policy.default.Window.sizeToContent", "noAccess"); *user_pref("capability.policy.strict.Window.open", "noAccess"); *user_pref("capability.policy.strict.sites", "http://ads4.clearchannel.com http://ad.doubleclick.net http://ads.x10.com"); *user_pref("dom.disable_open_during_load", true); OS: Windows 2000 (5.00.2195) Service Pack 2 (IE 5.0) Mem: 256 MB Compaq Deskpro, P3-650 desktop 1600x1200 @ 16-bit color (best the built-in adaptor can do) Win task manager info for Mozilla process: *threads (system total): 325 *processes (system total): 42 *page faults: 18,087 *Paged Pool: 35K *NP Pool: 12K *Handles: 193 *Threads: 8 *User Objects: 91 *GDI Objects: 321 *I/O Reads: 2,246 *I/O Writes: 274 *I/O Other: 4,707 *I/O Read Bytes: 3,113,453 *I/O Write Bytes: 670,975 *I/O Other Bytes: 490,866 Note, the above tests (and typing this) used 1:20 of CPU time (pretty high for how little I did).

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

As a consequence of the dupe, I'm changing platform to All. I saw the problem on Linux.

dbaron, can you look at this?

This bug now seems to be fixed in Linux build 2001-11-23-08. Whereas 0.9.6 leaks about 500k(!) per blank window that is opened and closed, the data segment size (memstat -w | grep mozilla-bin) for the above build is: one window -> open 10 blank windows with Ctrl-n <- close 10 windows with mouse click and Ctrl-w 13368 25524 25536 25552 25720 25720 25720 Good job, thanks!

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

> This bug now seems to be fixed in Linux build 2001-11-23-08 Thanks to bug 109671. I wonder if that was Linux only.

Issue still exists in 0.9.6 for Windows 2000. Started 21-22 megs. Opened 10 windows --> 29,616. Closed all 10 --> 28,560 Bummer :(

Invalid test, please re-run. Open 10 windows, close. Measure. Open 10 windows, close. Measure, compare. If this shows a significant increase, do it 10 more times and see if the increase continues. It's NOT necessarily a leak for not all the memory to be given back; it's a memory leak if the memory use continues to rise as you repeat the action. There are many reasons for that sort of issue, such as initial fragmentation, filling of internal object caches, etc.

OK, this is my test (Build ID 0.9.6 - 2001112009) First test (withi new blank windows) Initial 22504 kb 5 ^N 5 close 30344 29364 32388 31812 34520 34248 36648 36304 38976 38640 41092 41096 43192 42828 Second test (with new blank tabs) Initial 22476 5 ^T 5 close 23704 23744 23804 23820 23836 23852 23884 23884 23912 23912 23940 23920 23964 23940 Using ^N (new windows) there is definitely some leak... as I hope that after 7 times "open 5 windows" any "cache" is filled (from 30 open&closed windows to 35 windows there is still almost 2Mb of added RAM). [BTW: using the browser fom 2-3 consecutive days the footprint is as big as 2-300 Mb, and I open only a few windows, without tabs 200 Mb was only "a day's work"] Tabs are much better and the increase of 200 Kb during the 35 opened and closed tabs (again 7 times 5 tabs at a time) can be explaied with object cache filling.

Grrrr.. numbers were meant to be on two columns for easier reading... but it seems that tabuklations are not well intepreted. I add them with plain spaces: Initial 22504 Initial 22476 5 ^N 5 close 5 ^T 5 close 30344 29364 23704 23744 32388 31812 23804 23820 34520 34248 23836 23852 36648 36304 23884 23884 38976 38640 23912 23912 41092 41096 23940 23920 43192 42828 23964 23940

> OK, this is my test (Build ID 0.9.6 - 2001112009) Given the fix in bug 109671, which landed 11/22, there is zero point in testing that build. You're flogging a dead horse (or is that dead snake; I can never keep my metaphors straight).

You're right.. it is pretty much solved in build 2001112803 Initial 21132 5 ^N 5 close 27580 24680 27624 25460 27660 26088 27716 26760 27732 27152 27800 27088 27756 26928 27840 26964 27784 27256 27796 27320 27908 27472 27888 27912

no longer an issue, marking FIXED.