Closed Bug 98835 Opened 23 years ago Closed 17 years ago

Memory not released after loading huge table and image containing pages?


(Core :: Graphics: ImageLib, defect)

Not set





(Reporter: chabotc, Unassigned)



(Keywords: memory-leak)


(3 files)

When i load a -huge- page, containing 808 thumbnails, each thumnail surounded by
a table which uses colspans/rowspans (for bevel effect), and style sheet for the
labels, the memory usage is huge (obviously).

However, when i got to a different site, browse for half an hour, etc. This
memory is not release.

Reloading the page causes the memory to increase with the (aprox) the same amount!

First page hit made mozilla mem usage go from 32Mb to 84Mb. Browsed for a while
on different sites, memory remained 'constant'.

Hit the page again, memory usage went up to 124Mb. browsed for a few minutes,
memory was still not going down.

Tried reloading the page again, and i had to kill the browser when it reached
196Mb memory usage.. it was staling my system.

It's my distinct impression that either the tables or the style sheet or the
images are not free'd from cache. Also the continuous increment on reload, makes
 me think this is a 'leak' and not 'cache' (if it was cache, why would the
memory increase on every page reload..).

I used mozilla version 0.9.3, build from srpms (srpms provided by releases dir).
Ever confirmed: true
I reconfirmed this bug (using the attached html file) using the 0.9.5 release.
When loading the page for the first time, the memory usage went from 37Mb to
51Mb, then reloading it again, causes the memory usage to go to 85Mb.

Pressing page-back, or going to another URL (from bookmarks, or manualy typed
in), does not free this memory.
re-confirming the bug with 0.9.8 nightly releases. Behaviour is the same as
described above.

Severity: normal → major
Target Milestone: --- → Future
Keywords: mozilla0.9.9
Blocks: 51028
No longer blocks: 51028
Blocks: 124608
Taking this bug
Assignee: pavlov → nivedita
Can you please indicate the url for the above given testcase page. The 
attachment doesnt have the associated images.
Chris: your testcase is missing the images so we can't get much out of it,
please give us the original page url or an alternative testcase.
Ok, i've created a new testcase (basicly the same as the attached test case, but
then with a different look). You can find it, including images, at:
used the same html file but, since testcase attached by the reporter did not
have images, I have inserted sample images. I find that though memory increases
per reload, it does drop down after reaching some cut off. I have tried this on
NT. And when the page goes away from history, even then I observe drop in

Following are the observations of memory for the url reload
a) 32264K - > url -> loaded 
b) 62040K -> test page loaded
reloading the page from here on 
c) 75220K -> 1
d) 89176K -> 2
e) 103164K ->3
f) 114200K ->4
g) 126008K ->5
h) 137844K ->6
i) 148412K ->7
j) 160344K ->8
k) 172152K ->9
l) 174748K ->10
m) 176420K ->11
n) 180864K ->12
o) 187238K ->13
p) 187840K ->14
d) 186872K ->15
e) 77416K ->16
Keywords: qawanted
I have attached the purify trace. Trace shows potentials leaks in the
NS_NewCSSNameSpaceRule and NS_NewStyleContext. Hence, could some one from
layout confirm if this layout related.
assigning to layout to verify as per the purify logs
Assignee: nivedita → attinasi
Blocks: 130157
See also bug 130157.  There we can see that a bunch of memory _is_ released to
the allocator, but it was allocated on the C heap and the heap cannot be
compressed.  So the overall resident set size does not shrink....  (this is a
separate issue from the possible leaks Nivedita points out in comment 9).
Very strange... My results are completly different:

Mozilla 1.0

Quick Start - 17 mb ram.
One site runned ( - 24 mb (so alone site use 7 mb)

IE 6

one empty window - 7 mb
Loaded page (same) - 20 mb (alone site used 13 mb)


second test:

Mozilla 1.0

Quick Start,,,,, - 32 mb ram

IE 6

same pages - 28 mb ram, after while ( i never touched anything) 33 mb ram.

Mem leaks:

Mozilla 1.0

During closing next windows Mozilla didnt free ANY memory. (if there were 20
windows using 80 mb ram, after closing 19 of them it still use 80 mb!!!!).
But after closing last window, Quick start always restarts. After restart it use
16-17 mb.


Normally free mem during window closing.


Mozilla 1.0

tray+Mail&News (4 mail accounts i 2 news groups) - 23 mb ram (alone mail use 6

IE 6

Runned Outlook Express alone (process msimn.exe) - 17 mb !!!!!


Big tests

( mail + + + +
+ + + +
+ + + + )

Mozilla 1.0 - 52 mb ram (after closing all windows exempt mail 40 mb - so
Mozilla freed some memory.)

IE 6 - 50 mb process IEXPLORE.EXE and 17 MB process msimn.exe - together 67 mb

And last tests:

Mozilla 1.0 mail + same sites but in one window (tabs) - 42 mb ram !!!!!!!!!!

My conf - Windows 2k - Athlon 700 - 392 mb ram.

It looks like Mozilla use less ram than IE, but doesnt free anything. Second
thing is that ppl on said that on Windows XP Mozilla doesnt restart
Quick Start process and after closing all windows it still doesnt free any ram!!
(because Quick Start doesnt restart on WinXP - dunna know why).
Could this be related to bugs 131456, 157187, 81446, 149607?

Please see my comment in bug 131456 or 149607.


I just did some testing on a current build, and the only major memory increases
between the state before the page was loaded and after it was no longer
displayed (although I didn't let it finish loading because things are much
slower under the memory tools) was the image cache filling up.
Also somewhat relating to this - bug 174604
Assignee: attinasi → jst
Keywords: mozilla0.9.9mozilla1.3
OS: Linux → All
Hardware: Other → All
Target Milestone: Future → ---
What am I missing? Why did this imagelib bug get reassigned to jst, exactly?  
And please stop unsetting the target milestones on bugs.

Over to default owner.
Assignee: jst → jdunn
Sorry about the reassigning (thought this was layout and there is an info at )
Previous assignee was Attinasi -> new owner, new target milestone - right?
I fail to see any similarities between this bug and bug 174604.  And please do 
_not_ reassign attinassi's bugs unless you're assigning them to someone who 
plans to actually work on that particular bug and tells you so.  
*** Bug 213391 has been marked as a duplicate of this bug. ***
Blocks: 204374
No longer blocks: 204374
Keywords: mozilla1.3
Assignee: jdunn → nobody
QA Contact: tpreston → imagelib
Based on the current build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre), and the testcase ( above, I cannot reproduce the memory usage growth anymore.

So, marking as closed (until someone can proof that this specific issue is still there).
Closed: 17 years ago
Resolution: --- → FIXED
No bug for patch referenced as the fix.

Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.