Closed Bug 294452 Opened 20 years ago Closed 16 years ago

Memory for images will not be released correctly

Categories

(Core Graveyard :: GFX: Win32, defect)

Product:
Core Graveyard
Component:
GFX: Win32
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: daniel, Unassigned)

References

(
URL
)

Details

(Keywords: memory-leak) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Current releases of Firefox doesn't free memory of loaded images, even when
navigating to another page or closing a tab.
The latest trunk (17.05.05) releases memory after an image is loaded for the
second time!
This can be seen and reproduced at the given URL.

Reproducible: Always

Steps to Reproduce:
1. Add an image object to your document using JavaScript
2. Remove the first image object and add a second
3. Do so for a couple of large images

Actual Results:  
Memory will increase for every new image. It will be released when an image gets
created a second time.

Expected Results:  
Memory should be released when the image object will be removed or the src
property doesn't reference it anymore.

The current official release (FF 1.0.4.) is not usable for web applications
using a lot of images. The latest trunk seems still be affected in a different way.
I also checked that with the latest XULRunner trunk with the same result. So
this seems to be a core problem not just a FF problem.

I pretty much hope to see this fixed with the next release as XUL-development
and web based applications depends on it.

See also the initial post at npm.xpfe:
http://groups-beta.google.com/group/netscape.public.mozilla.xpfe/msg/7b529510131cf2a?rnum=1
I can't seem to reproduce this with a current Linux trunk build (and memory
cache capacity set to 0).
I havn't tested this on Linux as this is not our target platform. I tested it on
Windows XP as this will be used by most of our customers.
I can reproduce this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4. Sorry, but currently I don't have a
nightly build. I'll test this later. A better example for the memory leak you
will find at the updated URL.
URL: http://www.birgin.de/test/js/bild_spe... → http://www.fotocommunity.de/pc/pc/cha...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry, the build which I specified in my last comment works fine. The image from
the URL is displayed by a java applet (this should be another bug). But with the
original URL and Fx1.0.4 I can still reproduce this bug on a system running
WinXP. Win2k doesn't show this behavior on different installations.

Reporter, do you have non WinXP machines? It would be helpful, if you could do
some tests on that machines.

=> Restoring old URL.
URL: http://www.fotocommunity.de/pc/pc/cha... → http://www.birgin.de/test/js/bild_spe...
I can confirm that behaviour on a win2000 SP4 machine.
Please DO NOT confirm bugs unless you can reproduce them in a current trunk
build.  In any case, don't confirm them without moving to the right component
(which this is clearly not).  Reassigning to confirmer to make sure this ends up
in the right place after appropriate testing.
Assignee: nobody → hskupin
Daniel, all I'm saying is that I can't reproduce the problem.  Which means I
can't really help with this bug (presumably the reason you cced me) until more
information comes from somewhere...
Actually I ccep you because you told me so :-)
"Please file a bug and cc me [...]"
<d69ai5$m7h1@ripley.netscape.com> in netscape.public.mozilla.xpfe

The latest nightly [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050614 Firefox/1.0+] shows the same result. The memory gets freed after
a second load of an image (WinXP SP2).

To which component should this bug belong to?
Maybe Core:GFX:Win, if this is Windows-only...
Assignee: hskupin → win32
Component: General → GFX: Win32
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
(In reply to comment #6)
> Please DO NOT confirm bugs unless you can reproduce them in a current trunk
> build.  In any case, don't confirm them without moving to the right component
> (which this is clearly not).  Reassigning to confirmer to make sure this ends up
> in the right place after appropriate testing.

Boris, sorry I know that was a little bit overhasty. But meanwhile I tested
shortly with a trunk build and can reproduce it only on machines running Win32.
Linux builds aren't affected. Today I hadn't time to make detailed tests.

Daniel, could you write down the memory usage when switching through the list of
images? It would be helpful when we could see it e.g. inside a table.
So if someone with a debug build can see this, it's worth setting
XPCOM_MEM_LEAK_LOG=c:\whateverfile.log and starting mozilla and then looking at
the log after you reproduce the problem.  That will at least indicate whether
this is a permanent leak (through shutdown)....
OK, here are some (interesting) news and the results from my memory usage test:
[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050614 Firefox/1.0+]

Starting Firefox: 17.660K
Typing in the URL (opens the autocomplete menu): 18.552K
Loading the page (no image shown so far): 19.008K
Img 1: 22.928K (25KB jpg)
Img 2: 23.284K (6KB jpg)
Img 3: 27.136K (43KB gif)
Img 4: 26.800K (2.5KB gif)
Img 5: 27.044K (21KB gif)
Img 6: 30.048K (143KB jpg)
Img 7: 32.920K (68KB Jpg)

All images are created once now.
Restarting with img 1 with the next click.
Img 1: 29.448K
Img 2: 29.068K
Img 3: 25.220K
Img 4: 25.220K
Img 5: 25.220K
Img 6: 21.948K
Img 7: 23.648K

Restarting again:
Img 1: 19.852K
Img 2: 19.852K
...

To be able to reproduce this, I must always clear my cache before loading the page.

Now comes something interesting:
If I load the first image memory is about 23.000K. I then switch the focus to
another application and back to firefox, memory goes down to 19.100K, even if
the other application (Notepad) is a pretty small window. So setting the focus
again seems to call garbage collection or something like that.
Maybe it's just a garbage collection problem?

It seems as if small images are handled better.

(Current official builds ends up with about 3-5MB more memory usage and doesn't
free it no matter how often I restart. Even when leaving the page.)
URL: http://www.birgin.de/test/js/bild_spe... → http://birgin.de//test/bugzilla/bild_...
Daniel, do you have the potentiality to build a win32 debug build and test the
hint given by bz in comment 11? I don't have a win32 build system available.
No, I've never created my own build. But if you show me how to do it...
(In reply to comment #14)
> No, I've never created my own build. But if you show me how to do it...

Sure. Let's do that in a pm session. So we don't spam this bugreport.
Daniel, does this still happen with the latest trunk builds of xulrunner?
Thanks for the reminder.

I've tested the given URL: http://www.birgin.de/test/bugzilla/bild_speicher_freigeben.html 
with the latest XULRunner nightly (2008.05.08) and it seems to handle memory better. (But the initial memory is much higher than for older XULRunner builds - around 19MB).

The used memory is not set free for each new image. It also seems that changing the focus to another window and back to the application will free some memory (not always) - see comment 12.

I've done the test several times and always got different results and behaviours so my assumption is, that it heavily depends on the garbage collection module.

As a summary:
The problem seems still be present but seems not that critical anymore. Freeing memory is better. Reproducing the problem is difficult, even with the given testcase as the results always vary.
BTW:
The XUL I've used to test the behaviour in XULRunner:

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>


<window
   title      = "WindowTitle"
   width      = "1024"
   height     = "768"
   orient     = "vertical"
   xmlns      = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<script type="application/x-javascript">
function goToUrl() {
    var url = document.getElementById("url");
    document.getElementById("contentframe").setAttribute("src",url.value);
}
</script>

    <hbox>
        <textbox id="url" value="" flex="1" onkeydown="if (event.keyCode == 13) goToUrl()"/>
        <button label="GO" oncommand="goToUrl()"/>
    </hbox>

    <iframe id="contentframe" flex="1" style="background-color:#fff"/>
</window>
Carsten, would this be a part where you could have a look at?
Keywords: mlk
(In reply to comment #17)
> Thanks for the reminder.
> 
> I've tested the given URL:
> http://www.birgin.de/test/bugzilla/bild_speicher_freigeben.html 
> with the latest XULRunner nightly (2008.05.08) and it seems to handle memory
> better. (But the initial memory is much higher than for older XULRunner builds
> - around 19MB).

Hi Daniel, i did some testing around the Testurl with my Firefox Debug Builds and a Firefox 3 Nightly Build and Leak Gauge and i got no Memory Leak Report:

Results of processing log leak4.log :

Summary:
Leaked 0 out of 15 DOM Windows
Leaked 0 out of 47 documents
Leaked 0 out of 7 docshells
Leaked content nodes in 0 out of 54 documents

Memory Use on the Firefox 3 Nightly Build with XP SP3 went up 15 MB when i used your testcase but also was going back to normal (around 50 MB RAM usage).
Carsten, thanks for the test. I have not used Leak Gauge. All I've done was checking the memory usage in the windows task manager.
The original problem was detected, because memory increased a lot and never seemed to be released in our (formerly) Firefox based application the more images we used.

I'm not sure how to handle the issue and if there finally is still a problem or if the results I get are usual memory variations. The big problem, where every newly loaded image leaked nearly all of it's used memory, is not reproducable with newer releases anymore. So if you don't see any reason to act here I would now just mark this as "WORKSFORME" and I would file a new bug in case I detect something more serious and reproducable.
Marking WFM per original reporter's comments.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.