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

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Chris]

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).

Comment 1

[Chris]

Attachment: This is the HTML file, which causes it to eat memory like candy (local alysa millano pic collection) to demostrate image/table layout (ofcource without images, be to large)

Comment 2

[Chris]

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.

Comment 3

[Chris]

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

Comment 4

[Nivedita (gone)]

Taking this bug

Comment 5

[Nivedita (gone)]

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

Comment 6

[basic]

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.

Comment 7

[Chris]

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

[Nivedita (gone)]

Attachment: The attachment is a .Zip file having the test case

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

[Nivedita (gone)]

Attachment: .tar.gz file having trace on running purify on the test case

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

[Nivedita (gone)]

assigning to layout to verify as per the purify logs

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

[Christian Hamacher]

Could this be related to bugs 131456, 157187, 81446, 149607?

Please see my comment in bug 131456 or 149607.

Greetings,

  -Chris

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Markus Hübner]

Also somewhat relating to this - bug 174604

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.

Comment 17

[Markus Hübner]

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

[Boris Zbarsky [:bzbarsky]]

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

[Daniel de Wildt]

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

Comment 20

[Alfred Kayser]

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).

Comment 21

[Jason Bassford]

No bug for patch referenced as the fix.

-> WORKSFORME