Closed Bug 269523 Opened 20 years ago Closed 18 years ago

Memory keeps growing on this page

Categories

(SeaMonkey :: General, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041110 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041110 Firefox/0.9.1+

This was reported here before:
http://forums.mozillazine.org/viewtopic.php?t=160116&start=0&postdays=0&postorder=asc&highlight=

When I visit that url and let the photos pass by one by one, I see the vm size
on my computer rise by appr. 2MB per photo.
When I close that page or leave it, all the vm size gets normal again.

I'll attach a testcase.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Attached file Top frame
The top frame writes (see the code) after a second a new image in the bottom
frame. But it writes in with an onload handler with a function call that
triggers a new timer of 1 second that loads the following image in the bottom frame.
That seems to be the cause of the growing memory. When removing that onload
handler and instead use a setinterval to load a new image every 1 second, I
don't get to see the growing memory usage.

Another experiment: press the 'reload this frame' after you've seen some images
gone by. The image loop starts new, but the memory usage does not get increased,
until a new image, that hasn't been loaded previously in the loop, gets loaded.
Also, I would expect that every time after 1 second a new image gets loaded. But
this time they get loaded much faster after each other, which is rather strange,
I think.

This seems like a regression:
I don't think I really see the VM size grow with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040312
Firefox/0.8.0+
But I think I see the VM size grow with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040314
Firefox/0.8.0+ 
Keywords: regression, testcase
So... with a current trunk Linux build, I see VM usage oscillate between 27MB
and 29MB as the various photos load.  Gone through 60 photos so far, and the
memory is not growing.

So if there is an issue here, it's Windows-only....
Ok, I've backed out the "DIB sections patch, updated again" patch from bug
205893 in my debug build, and after that the VM size doesn't seem to grow
anymore with the testcase.
Ccing people from that bug....  Are we forgetting to clean up something?
I'll check.
I see the GDI handle usage increase all the time with or without the mentioned
patch backed out (don't know if this is because of memory cache or a leak). With
the patch backed out the image memory seems to be released right before the next
one starts to load. This doesn't happen with the patch in. As far as I can see,
the patch itself doesn't change anything regarding resource allocations, so I
assume the actual problem lies elsewhere. 
If nothing else, the only place mHBitmap is deallocated is CleanUpDDB(), which
seems to only be called from the destructor.  I see a number of assignments to
mHBitmap... could we simply be leaking the objects it points to?
(In reply to comment #5)
> Ok, I've backed out the "DIB sections patch, updated again" patch from bug
> 205893 in my debug build, and after that the VM size doesn't seem to grow
> anymore with the testcase.

This may be the case because of strange graphics memory allocation behaviour of
some video drivers. If a driver allocates the images in graphics memory you will
not see any traces of it looking at the VM usage in task manager.

As ere noted already, the patch does not change allocation behaviour. If
something is leaked, it is so with or without the patch. It may be hidden deep
inside some video driver, however, and not come to one's attention immediately
because of that.
I didn't have time to check yesterday, but now I checked and yes, it seems we
leak bitmaps heavily. And not only in this test case.. 
Status: NEW → ASSIGNED
Assignee: general → emaijala
Status: ASSIGNED → NEW
Oops, my previous test was flawed. We are leaking images, but it's not because
of leaving old mHBitmaps dangling. We seem to be leaking the whole nsImageWin
objects.
Product: Browser → Seamonkey
This isn't just Win32 issue. The same problem exists on Linux and I'd bet on
other platforms too, but it depends on the platform how it shows. On Linux it's
the X server that gets the memory load, not the Firefox process. I'm removing
the regression keyword as I'm not sure this is a regression at all.

My guess is that the image is somehow left in memory because it's the source of
the onload event or something like that, but it's a bit out of my domain of
knowledge.
Assignee: emaijala → general
Keywords: regression
OS: Windows 2000 → All
So, it looks like the images are just in the memory cache (open about:cache
while looking at that testcase and reload it a couple of times).  Closing the
tab clears out the memory cache.

So it seems that for some reason the image nodes are not going away until we
close the tab (which causes a GC and also happens to tear down the document).

jst, sicking, peter, any idea what could be holding refs to the image nodes?
Keywords: regression
Blocks: mlk1.8
I'm not seeing any problems with the original URL or with the testcase. In Firefox 1.5.0.1 on Windows XP SP2 with a new profile, after running both tests for hundreds of images, Peak Mem Usage is 66 MB and the VM Size is below 60 MB; considering I have a full 31 MB memory cache, that memory usage seems very reasonable. The memory cache capacity is never exceeded. The number of GDI objects stays below 200. I get similar results in SeaMonkey 1.0 on Windows XP SP2 with a new profile.
Indeed, I'm not seeing the original problem anymore.
Still a problem in 2005-03-04 07 build, but works in 2005-03-06 08 build.
With the 2005-03-06 build, I get almost no memory growth at all.
I bet bug 284716 fixed this.

But between the 2005-05-09 06 build and the 2005-05-10 07 build, I'm seeing a regression. Before, I didn't see any memory growth at all (Firefox stays at appr. 25MB), after I get a memory growth until appr. 50MB and then the memory growth stops. Closing the tab doesn't release memory. However, when I load the testcase again, then suddenly memory gets released after loading every new picture (which load very fast now, because they're cached), until 25MB is reached and after that memory usage increases again.
This is also the situation in current trunk build.
I bet bug 292051 might have something to do with this.

CC-ing Arron, he might now what's happening here.
I could reproduce this Problem with my official 1.5.0.1 and was finally able to track this down to Adblock beeing the culprit!

With Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1, a completely new Profile, just the latest Adblock 0.5.3.042 from https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=10
and all settings left at default, about:cache showed Storage in use constantly growing and Inactive storage left at 0 when trying the latest testcase (Parent frame).

Also the latest Adblock Plus 0.5.11.2 from http://www.extensionsmirror.nl/index.php?showtopic=774&hl=adblock did have the same Problem.

There is now another Adblock Plus 0.6.1.1 https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=1865 that has a new developer, is a completely new rewrite (and therefore "co-exists"  with the others) and seems to dont have this memory-growing bug.

Given that Adblock is Top #4 of Extensions and the (original) Adblock Plus also very popular, I think this might very well be one of the most important reasons why people complain about FF using enormous amount of memory after a while...

Going to try to point both concerned Developers to this bug. 
Unfortunately, also Adblock Plus 0.6.1.1 shows "Inactive Storage" stuck at 0 and "Storage in use" climbing constantly, but only with the (real World) URL-testcase (unlike the other Adblock Extensions).
Stebs, please no more comments about Adblock. This bug is happening without using Adblock. I suggest you file a new bug on the issue you see.
With current Cairo trunk builds, memory seems to every time a new image loads, with no limit on it. closing the tab seems to release the memory, however.
I guess I should file a new bug on the cairo builds?
(In reply to comment #20)
> memory seems to every time a new image loads, with no limit on it.
Mozilla family currently doesn't have memory cache size limit for already opened page. See Bug 213391.
Same problem of Cairo? 
Original URL and testcase WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1. Peak Mem Usage is 58 MB and the GDI objects stay under 250. Does anyone see any problems with memory usage or GDI objects with these pages?
Indeed, current trunk builds seem to work fine.
But I can still see it using an extra 15MB memory after a few photos have been loaded (but memory usage doesn't increase further). Closing the page doesn't help with releasing that memory.
Not sure if that's a problem. 
But the original problem is certainly gone, I would have no problem if this bug is going to become wfm now.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
(In reply to comment #23)
> But I can still see it using an extra 15MB memory after a few photos have been
> loaded (but memory usage doesn't increase further). Closing the page doesn't
> help with releasing that memory.
> Not sure if that's a problem. 

Of course it *IS* a problem, if page is closed, and images related to it are not released from memory...
But I think there is another bug for that problem.
(In reply to comment #24)
> Of course it *IS* a problem, if page is closed, and images related to it are
> not released from memory...

No, that's the normal operation of the memory cache. It's by design and not any sort of bug. If you still think there's some sort of bug, please post a link to it here so others can find it.
(In reply to comment #25)
> No, that's the normal operation of the memory cache. It's by design and not any
> sort of bug. If you still think there's some sort of bug, please post a link to
> it here so others can find it.

There is a bug with this problem:
Memory not released after loading huge table and image containing pages
Bug 98835
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: