Closed Bug 93547 Opened 23 years ago Closed 23 years ago

Memory leak after opening multiple browser windows


(SeaMonkey :: General, defect)

Not set


(Not tracked)



(Reporter: bugzilla3, Assigned: dbaron)



(Keywords: memory-leak)

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.
Keywords: mlk
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 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
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.

UTIL            STEP1    STEP3   STEP3-STEP1
Win Task Man.   16100    20016   3916 KB
SpyGuru          8462    12275   3813 KB

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
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
Assignee: asa → 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.

Ever confirmed: true
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 ?
Anyone think this could get into 0.9.4?
-> cathleen for a new home
Assignee: dprice → asa
If the browser actually loads a page, then the leak is much higher

In this example I have set the home page to

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
Keywords: mozilla0.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).
Blocks: 92580
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
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 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 set as my homepage:

Start Mozilla:
19872 k

Open same as above:
33692 k
No longer blocks: 92580
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 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:

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
new window performance
Window opening times get really slow after opening multiple browser windows (on
New browser windows take up to 6 seconds to open on an Athlon 1.2Ghz!
Browser does not open new windows
68002 in javascript should be faster
(the following contains links to some more technical bugs that might help) 
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

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.
Assignee: asa → 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.
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

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.

Glen, please read my previous response to your comments in this bug.  Thanks.
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)
**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("", "noAccess");
*user_pref("capability.policy.strict.sites", "");
*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
OS: Windows 2000 → All
dbaron, can you look at this?
Assignee: cathleen → dbaron
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


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

Second test (with new blank tabs)

Initial 22476

5 ^T	5 close

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

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.
Closed: 23 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.