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)
1.35 MB, text/html
105.55 KB, application/octet-stream
568.95 KB, application/octet-stream
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
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
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: http://www.chabotc.com/testcase/
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
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
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.
Also somewhat relating to this - bug 174604
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 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.
*** Bug 213391 has been marked as a duplicate of this bug. ***
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 (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
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.