Closed Bug 326611 Opened 19 years ago Closed 18 years ago

Memory leak browsing large image gallery on somethingpositive.net

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: schapel, Unassigned)

References

()

Details

(Keywords: memory-leak)

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.somethingpositive.net/
2. Scroll down the page and click on the Previous Comic link
3. Repeat step 2, and every 20 or so pages, stop and view the memory usage

When I did this, I saw memory usage increase every time I viewed it. The
strange thing is that while you're watching the memory usage, it continues to
climb upward even through the browser doesn't seem to be doing anything. After
about a minute, the memory levels off, and the next time you check the memory
usage it does the same thing. The memory usage appears to grow without limit.
If you don't see the memory use grow upward at first, just watch it for at
least a minute and see if it starts to climb.

The way you scroll down the page makes no difference. I've used the mouse
wheel, scrollbar, and keyboard navigation. The number of pages you visit in
between checking the memory usage doesn't seem to matter -- it is reproducible
with opening just 1 page and checking, or opening 30 pages and checking.

I've reproduced this problem with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.9a1) Gecko/20060128 Firefox/1.6a1 and SeaMonkey trunk build
20060128. I have no additional extensions or themes. The leak gauge reports no
objects leaked. The maximum capacity of the memory cache is never exceeded.
Turning of bfcache seems to have no effect. Opening a new tab after the memory
usage has grown releases only a tiny amount of memory. I've been able to get
Firefox to consume 300 MB of additional memory doing nothing but the steps
above.

I also see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
Gecko/20060201 Firefox/1.5.0.1, freshly installed with a new profile, so this looks like an issue that should be addressed for Firefox 1.5.0.2.
Summary: Memory leak browsing large image galleries → Memory leak browsing large image gallery on somethingpositive.net
I'm curious what large things are leaking without being caught by leak-gauge.  My guess is "something related to images".
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060209 Firefox/1.6a1 ID:2006020906
I totally don't see this. Memory usage stayed under 23MB for me no matter how many comics I viewed. Also, leak-gauge.pl reported no leakage.
Do you see this excessive memory usage with a new profile?
Also, http://forums.mozillazine.org/viewtopic.php?t=354828 may help.
Read my comments above. In my tests, leak-gauge never reported any objects leaking. I'm using Firefox 1.5.0.1 freshly installed (after completely uninstalling all previous Firefox and SeaMonkey browsers and deleting all files associated with them) with a new profile. I do have SeaMonkey 1.0 installed using its own profile. And in Firefox 1.5.0.1 I do have the Developer Tools and Quality Feedback Agent installed. Maybe the problem was fixed on the trunk in the last week or so; if so, we should make sure the fix gets on the branch. I can reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060209 Firefox/1.5.0.1 installed over Firefox 1.5.0.1 -- I got Mem Usage and VM Size to go well over 100 MB within minutes.
I don't see it either.

Here are my results:
Mem.Cache  |  Mem.  |  VM
3.4 MB     |  20.6 MB  |  12.3 MB
after step 2, 20 times:
18.3 MB    |  38.7 MB  |  29.6 MB
after 20 more steps
16.8 MB    |  37.3 MB  |  28.4 MB

Memory use and VM use did increase during the first 20 steps, but that is attributable to filling the Memory Cache Device (about:cache).  No further increase was observed.  I did have to wait for a couple of minutes after scrolling to get an accurate memory use.  Using Task Manager, scrolling often appears to deflate memory use temporarily, with Fx and other applications.  Final memory use was actually rather low.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Essentially default configuration, but Java is disabled.  NO extensions, default theme.
very very important.  those of you unable to reproduce this bug, disable adblock, your hosts file, and any other ad blocker you may have.  memory usage remains exactly the same when i have my hosts file and adblocking css intact, but skyrockets up with each click when i have all ads shown.
I tried viewing 20 comics but the memory stayed at 28-29mb. Maybe the bug depends on a type of ads displayed on that page?
btw, i tested with ff 1.5.0.1 on win2k
I tried reproducing with Firefox 1.5.0.1 without Developer Tools installed. I made another completely clean install with a new profile, and after about 100 pages Mem Usage is at 155 MB with this displayed in about:cache:

Memory cache device
Number of entries: 	134
Maximum storage size: 	31744 KiB
Storage in use: 	123282 KiB
Inactive storage: 	0 KiB

Almost all the entries in the memory cache are of the form:
http://www.somethingpositive.net/arch/*.gif

Each of these files is about 1 MB and seem to all be the graphics files for the comics. I wasn't seeing this behavior of the memory cache before, and I'm not sure why it's different now. The other strange thing is that even as the Mem Usage rises after I've stopped loading new comics, the storage in use by the memory cache stays constant.

I tried setting browser.sessionhistory.max_entries and browser.sessionhistory.max_total_viewers both to 0 and restarting Firefox, and I get the same behavior, so it doesn't look like the bfcache is causing this problem.
See Bug 249469 which has been put in dependency tree of Bug 320915 on 2006-02-03.
Same problem as Bug 249469?
Are you able to repro with recent trunk/1.8 branch
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3)
Gecko/20060626 BonEcho/2.0a3. The total memory usage stays below 60 MB. The
memory cache stays within its default limit of 18 MB. leak-gauge.pl reports 0
leaks.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry... it's WFM.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.