Closed
Bug 98835
Opened 23 years ago
Closed 17 years ago
Memory not released after loading huge table and image containing pages?
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: chabotc, Unassigned)
References
Details
(Keywords: memory-leak)
Attachments
(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
ftp.mozilla.org releases dir).
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
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
Updated•23 years ago
|
Target Milestone: --- → Future
Keywords: mozilla0.9.9
Comment 5•23 years ago
|
||
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:
http://www.chabotc.com/testcase/
Comment 8•23 years ago
|
||
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
memory.
Following are the observations of memory for the url reload
a) 32264K - > url ->mozilla.org 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
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
assigning to layout to verify as per the purify logs
Assignee: nivedita → attinasi
Comment 11•23 years ago
|
||
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).
Comment 12•22 years ago
|
||
Very strange... My results are completly different:
Mozilla 1.0
Quick Start - 17 mb ram.
One site runned (sports.pl) - 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,http://mozillapl.org,sports.pl,onet.pl,wp.pl,hoga.pl - 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.
IE6
Normally free mem during window closing.
------------------------------------------------------
Mail
Mozilla 1.0
tray+Mail&News (4 mail accounts i 2 news groups) - 23 mb ram (alone mail use 6
mb!!!!!)
IE 6
Runned Outlook Express alone (process msimn.exe) - 17 mb !!!!!
-------------------------------------------------------------
Big tests
( mail + http://onet.pl + http://wp.pl + http://alladyn.art.pl + http://hoga.pl
+ http://www.rd2.cz + http://yahoo.com + http://sports.pl + http://altavista.com
+ http://allegro.pl + http://microsoft.com + http://www.netscape.com +
http://mozillapl.org )
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
ram!!!!
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 mozilla.pl 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).
Comment 13•22 years ago
|
||
Could this be related to bugs 131456, 157187, 81446, 149607?
Please see my comment in bug 131456 or 149607.
Greetings,
-Chris
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
Also somewhat relating to this - bug 174604
Assignee: attinasi → jst
Keywords: mozilla0.9.9 → mozilla1.3
OS: Linux → All
Hardware: Other → All
Target Milestone: Future → ---
Comment 16•22 years ago
|
||
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
Comment 17•22 years ago
|
||
Sorry about the reassigning (thought this was layout and there is an info at
http://bugzilla.mozilla.org/show_bug.cgi?id=174604#c1 )
Previous assignee was Attinasi -> new owner, new target milestone - right?
Comment 18•22 years ago
|
||
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.
Comment 19•21 years ago
|
||
*** Bug 213391 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Keywords: mozilla1.3
Updated•18 years ago
|
Assignee: jdunn → nobody
QA Contact: tpreston → imagelib
Comment 20•17 years ago
|
||
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 (test.zip) above, I cannot reproduce the memory usage growth anymore.
So, marking as closed (until someone can proof that this specific issue is still there).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 21•17 years ago
|
||
No bug for patch referenced as the fix.
-> WORKSFORME
Resolution: FIXED → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•