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

RESOLVED WORKSFORME

Status

()

defect
--
major
RESOLVED WORKSFORME
18 years ago
5 years ago

People

(Reporter: chabotc, Unassigned)

Tracking

({memory-leak})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

18 years ago
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.
(Reporter)

Comment 3

18 years ago
re-confirming the bug with 0.9.8 nightly releases. Behaviour is the same as
described above.

Severity: normal → major

Updated

18 years ago
Target Milestone: --- → Future

Updated

18 years ago
Keywords: mozilla0.9.9

Updated

18 years ago
Blocks: 51028

Updated

18 years ago
No longer blocks: 51028

Updated

18 years ago
Blocks: 124608

Comment 4

17 years ago
Taking this bug
Assignee: pavlov → nivedita

Comment 5

17 years ago
Can you please indicate the url for the above given testcase page. The 
attachment doesnt have the associated images.

Comment 6

17 years ago
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.
(Reporter)

Comment 7

17 years ago
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

17 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

Updated

17 years ago
Keywords: qawanted

Comment 9

17 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

17 years ago
assigning to layout to verify as per the purify logs
Assignee: nivedita → attinasi
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 (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).
Could this be related to bugs 131456, 157187, 81446, 149607?

Please see my comment in bug 131456 or 149607.

Greetings,

  -Chris
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

17 years ago
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

Comment 17

17 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?
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

15 years ago
*** Bug 213391 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 204374

Updated

15 years ago
No longer blocks: 204374

Updated

15 years ago
Keywords: mozilla1.3
Assignee: jdunn → nobody
QA Contact: tpreston → imagelib

Comment 20

12 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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 21

12 years ago
No bug for patch referenced as the fix.

-> WORKSFORME
Resolution: FIXED → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.