Closed Bug 174760 Opened 22 years ago Closed 22 years ago

Memory leak when loading jpg images

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: c.hamacher, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: memory-footprint, memory-leak, perf) 

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021013
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021013

Loading jpg images leaks memory - depending on the size of the image, this can
be massive.
Even if you reload the same image over and over again, you will eventually
exhaust all virtual memory, and the machine will grind to a halt. Mozilla will
need to be restarted to get the system back to an operational state.
I'm reporting this on Win NT4.0, but I can also observe the problem on a current
Linux CVS build.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla Browser
2. Load a jpg image
3a. Repeatedly reload the same image (Shift+Reload)...
3b. ... or load different jpg images one after the other
4. Observe total memory usage grow beyond all bounds in your favorite system
monitor tool

Actual Results:  
Memory usage grows with each image load/reload, until all virtual memory is consumed

Expected Results:  
Loading / reloading should first free all memory used for the current image, and
then load the new image. Repeatedly reloading the same image should result in
constant memory consumption. Viewing different images one after the other should
not show cumulative memory consumption.

The problem is (almost) independent of the size of memory/disk cache, and of the
activation of these caches.
It exists even if memory and disk cache are set to zero in Advanced | Cache, or
if they are disabled altogether in Debug | Networking.
If the caches are active and non-zero, the problem only manifests in step 3a if
I use 'Shift+Reload' to reload the image - a simple 'Reload' will not lead to
memory leakage.
The amount of lost memory correlates with the size of the viewed image. To see
the full impact of the bug, try viewing e.g. large DigiCam pictures. I was able
to exhaust 200MB of virtual memory within 20 minutes while browsing a friend's
photo archive.

I'm filing this with severity 'critical', since the browser can quickly hang due
to lack of memory. If anybody feels that's an exaggeration, please feel free to
reduce to 'normal'.

By the way: I *do* know that this bug is closely related to bugs 171681, 158805, 
157187, 98835, 131456 and 174604 - and I am *not* trying to get attention by
filing gratuitious bugs on known issues. Rather, the previous bugs include
aspects like tabs/windows, javascript, tables, DOM, cache settings, questions of
the memory monitoring tool used, and different types of page content.
These bugs either only partially overlap, or they don't present the minimal test
case. I'm trying to present a reduced test case here.
footprint, perf -> keywords

I forgot to mention that the problem is independent of whether the jpg is local
(file:// - type URL) or remote (http:// - type URL).
Keywords: footprint, perf
Can you attach testcase ?
Giving example URL for testing (workplace-safe).

The page contains several thumbnails, which link to large-ish (~400kB) JPGs.

You can either click on one thumbnail, click back, click on another one (lather,
rinse, repeat ...) , or you can choose one image and 'Shift+Reload' it over and
over again - in both cases, you will see memory consumption continuously
increase, and memory will not be freed if you close the window/tab in which you
did the test.
URL: http://www.ist-drive.org/ifa.html
bug 157187 has a good testcase, but unfortunately isn't workplace-safe!  :)

The page has a meta refresh and I believe the images are set to not cache.  
(when the meta refresh reloads the page, new images are retrieved if they've
changed)

This is a very severe problem in that if Mozilla is left open on that page, it
will continue to eat up RAM until the system becomes nearly unusable.

Confirming, but I have the feeling that the issue at hand here is the same as
with  bug 157187
Status: UNCONFIRMED → NEW
Ever confirmed: true
Doh! Backpedaling:
I can't reproduce this on Linux anymore ... I have no idea what I changed :-(
Changing platform to 'NT'.
Sorry!
OS: All → Windows NT
Keywords: mlk
I can confirm this on WinXP.
OS: Windows NT → All
I tried this under Valgrind.  Reloaded car2.jpg from the URL (locally) about 12
times.  Valgrind came up with this:

676 bytes in 13 blocks are possibly lost
 malloc (vg_clientfuncs.c:100)
 __builtin_new (nsAppRunner.cpp:178)
 operator new(unsigned) (vg_clientfuncs.c:139)
 NS_NewHTMLImageElement() (nsHTMLImageElement.cpp:181)
 nsImageDocument::CreateSyntheticDocument() (nsImageDocument.cpp:329)
 nsImageDocument::StartDocumentLoad() (nsImageDocument.cpp:265)
 nsContentDLF::CreateDocument() (nsContentDLF.cpp:435)
 nsContentDLF::CreateInstance() (nsContentDLF.cpp:233)

and
1040 bytes in 13 blocks are possibly lost
 malloc (vg_clientfuncs.c:100)
 __builtin_new (nsAppRunner.cpp:178)
 operator new(unsigned) (vg_clientfuncs.c:139)
 nsScriptSecurityManager::GetCodebasePrincipal() (nsScriptSecurityManager.cpp:1744)
 nsDocument::GetPrincipal() (nsDocument.cpp:915)
 GlobalWindowImpl::GetPrincipal() (nsGlobalWindow.cpp:895)
 nsScriptSecurityManager::GetPrincipalAndFrame() (nsScriptSecurityManager.cpp:1876)
 nsScriptSecurityManager::GetSubjectPrincipal() (nsScriptSecurityManager.cpp:1895)

the first chunk looks more relevant, but both have lucky number 13.
Is this 158805?
MacOS9 trunk builds eats up 0.6 to 0.9MB of memory when it displays a jpeg file
of 100 to 200kB.
> Is this 158805?

There are a lot of bugs like bug 158805 (see bug 11048), but I could not
reproduce a real leak on those bugs.  Mozilla's RAM goes up for a while, but
eventually goes back down.

Andrew, what OS did you try this on? I had Mozilla consume more than 200MB of
memory on Win NT4.0 and 98. At this point, the browser crashed due to lack of
virtual memory. At what size did you see memory usage level off?

As I wrote in comment #5, I cannot reproduce the problem on Linux. The problem
under Win persists for me with a current nightly (Mozilla/5.0 (Windows; U;
WinNT4.0; en-US; rv:1.2b) Gecko/20021107)
> There are a lot of bugs like bug 158805 (see bug 11048), but I could not
> reproduce a real leak on those bugs.  Mozilla's RAM goes up for a while, but
> eventually goes back down.

The RAM usage for the mozilla/phoenix process goes up and then drops again, but
the amount of allocated virtual memory just increases. By reloading a high
quality jpeg about 100 times, I managed to get a VM usage of over 1 GB.
I am testing with linux.  For me, the JS image-swapping or meta-refresh stuff
does eat total allocated memory for a while, but it eventually goes back down.

I filed bug 179498 for the minor (in comparison) leak from comment 7 as it does
not really seem to be what Christian is seeing.
bug 157187 shows a case where the memory usage does *not* go back down.   It
will continually increase until the system becomes unstable.  Windows or Linux.
When memory usage exceeds the limit, the image is not displayed, and if View
image is eveoked, Mozilla displays something like "so_and_so.jpg can not be
displayed because it contains an error."
I do not like the expression of this error message, because it seems to put
blame on the image file, even if the viewer is having trouble from incomplete
data in cache or whatever in its workspace.
I have this problem on Phoenix and had this problem on Mozilla before switching
over. I use meta-reload as well as auto-reload using tabbrowser extensions and
the pages I use run up to 400 MB of memory doing not all that much. The load was
about 150 MB with Internet Explorer/Crazy Browser.

BTW, for those of you seeing that memory usage goes up and then comes back down,
it could be your OS stealing pages back from your application. Total VM increases
but actual memory is small as the OS pages out memory that hasn't been used for
a while.

I'm running Windows XP with no page file and 576 MB of memory so I know that I'm
not paging out memory. My current thought on a solution is to buy more memory.
This is serious and we shouldn't ship this problem in 1.3. Pavlov, who can help
us with this?
Flags: blocking1.3b+
bug 179498 has been fixed on trunk.  those of you seeing this bug might pull a
fresh nightly and see how much it helped with this bug.
I pulled the nightly (2002121408) and was planning to try it out on Monday but
this build has another bug with focus that was due to a fix and backed out but
there isn't a new nightly yet. If there's a 1215* label within a few hours, I'll
give that a try. The focus problem is too big a pain to live with during the day.
After updating to Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a)
Gecko/20021214, I can no longer reproduce my observation of memory leakage.

Therefore, for me this is fixed. If I get another positive confirmation that
this is fixed, I'll close this bug as FIXED.
Just upgraded to:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021216, build 2002121608

I can no longer reproduce this bug. Looks good to me.
2002121608 trunk for MacOS9.x works OK, too.
-> WORKSFORME, based on reporter's comment and the two confirmations.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Flags: blocking1.3b+
You need to log in before you can comment on or make changes to this bug.