Closed Bug 105370 Opened 23 years ago Closed 17 years ago

huge memory use loading a 2M animated GIF

Categories

(Core Graveyard :: Image: Painting, defect)

Product:
Core Graveyard
Component:
Image: Painting
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: jmd, Unassigned)

References

(
URL
)

Details

(Keywords: memory-footprint, perf)

Attachments

(2 files)

graph of cpu usage
19.03 KB, image/gif
Details
memory and cpu usage with firefox in safe mode
29.67 KB, image/gif
Details 
Allocating 108 meg to load this 2M image. Loading it via file:, and it's
reproducable.

Linux 095.
bugzilla's not liking the 2M upload. I'll have to put it elsewhere. Hang tight,
ping me if I don't update in a few days, in case I forget.
Keywords: mlk, perf
I just tried this one - and linux's OOM didn't kill mozilla unfortunately - I
caught mozilla using 400Megs before the machine became erm.... unresponsive. *cough*

http://astronomy.swin.edu.au/~cbrook/galaxy_anim_short.mov2.gif

4 meg animated GIF.
Target Milestone: --- → mozilla1.1
Blocks: 119597
Keywords: footprint
   This is a severe bug on solaris and linux, it take large mem and lead to 
machine down.


browser-china-ptf@sun.com
Component: ImageLib → Image: GFX
Target Milestone: mozilla1.1alpha → mozilla1.1beta
I just tried http://astronomy.swin.edu.au/~cbrook/galaxy_anim_short.mov2.gif on :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523

while watching the memory usage .. once it had grown 150MB I stopped the page
from loading to keep my computer from reaching a halt due to disktrashing.
After I had pushed "back" and returned to this page the memory usage dropped to
what it was before the site had loaded.
Yup, seeing it on WinXP too with Moz 1.0. -> All/All
On my Athlon 1200 with 768 megs of RAM:
While downloading the image (over my slow ISDN line), Moz takes 100% CPU, and
memory use increased to a whopping 468MB!
After it finished loading the image, the animation works fine (though a tad
slower than it should have), and Moz needs 100% CPU again to do it, and keeps on
using that much. (Moving to a different tab does gets the cpu down.) Closing the
window/tab with the image gets memory and CPU use back to normal levels again.
When loaded from the local disk, it takes Moz about 6 seconds before it displays
anything.

For comparison:
-IE needs 149MB of RAM for it, and when loaded from the local disk, the
animation starts instantly. After a short while of heavy CPU usage, it goes down
to <2% and stays down.

-The image viewer I use (ACDSee, www.acdsystems.com) has almost identical
behaviour as IE. It needed 143 megs of ram, and hardly any CPU usage.
OS: Linux → All
Hardware: PC → All
*** Bug 158305 has been marked as a duplicate of this bug. ***
I have seen this bug consistently as well with Mozilla 1.1:

http://neo.jpl.nasa.gov/j002e3/j002e3c.gif
http://neo.jpl.nasa.gov/j002e3/j002e3c.gif

I get the same problem with Win 98 in Phoenix/0.3 build 20021019.  It allocated
a couple of hundred meg from physical and virtual memory according to MemTurbo.
I see this bug with Chimera (on Mac OS X 10.2.3) also when viewing animations
referenced at
http://neo.jpl.nasa.gov/2002aa29.html
When loading a second 4 MB animated gif Mozilla 1.2.1 (20021203) crashed on my
HP-UX 11.00 machine and damaged XUL.mfasl. :-(
I think this should be reduced greatly (if not fixed) with the fix for bug 143046.
Depends on: slowGIF
I loaded the following image in Mozilla 1.3
(http://neo.jpl.nasa.gov/j002e3/j002e3c.gif), and the only major memory leak I
found in Purify was the following:

[W] MLK: Memory leak of 16992 bytes from 533 blocks allocated in PR_Calloc
[NSPR4.DLL]
        Distribution of leaked blocks
             16928 bytes from 529 blocks of 32 bytes (first block: 0x03b4d350) 
                64 bytes from 4 blocks of 16 bytes (first block: 0x0a5befe0) 
        Allocation location
            calloc         [dbgheap.c:456]
            PR_Calloc      [prmem.c:484]
            gif_write(gif_struct *,BYTE const*,UINT) [GIF2.cpp:1017]
            nsGIFDecoder2::ProcessData(BYTE *,UINT,UINT *) [nsGIFDecoder2.cpp:259]
            ReadDataOut    [nsGIFDecoder2.cpp:192]
            nsInputStreamTee::WriteSegmentFun(nsIInputStream *,void *,char
const*,UINT,UINT,UINT *) [nsInputStreamTee.cpp:105]
            nsPipeInputStream::ReadSegments((*)(nsIInputStream *,void *,char
const*,UINT,UINT,UINT *),void *,UINT,UINT *) [nsPipe3.cpp:717]
            nsInputStreamTee::ReadSegments((*)(nsIInputStream *,void *,char
const*,UINT,UINT,UINT *),void *,UINT,UINT *) [nsInputStreamTee.cpp:159]
            nsGIFDecoder2::WriteFrom(nsIInputStream *,UINT,UINT *)
[nsGIFDecoder2.cpp:279]
            imgRequest::OnDataAvailable(nsIRequest *,nsISupports
*,nsIInputStream *,UINT,UINT) [imgRequest.cpp:783]
*** Bug 201707 has been marked as a duplicate of this bug. ***
http://astronomy.swin.edu.au/~cbrook/galaxy_anim_short.mov2.gif
When loaded in a new tab:
firefox.exe process
Increased memory usage of 414,344 KB
I/O Perfomed 1029 Reads and 3 Writes to Disk
OS: Windows NT 5.1 Build 2600 SP1
Nightly build: FIREFOX.EXE Date: 12 June 2004, 6524928 bytes.
*Definately* a memory leak.
Seems it is not limited to animated GIF file, but common GIF file rendering
routine issue. A html document with ten or so GIF files (with size shrink)
linked consumes > 500 MB of memory.
Depends on: 274391
The identified MLK (the calloc at GIF2.cpp:1017) will be fixed with bug 274391.

The attached gifs still cause a lot of memory allocated because GIFs are always
decoded to 24bits, so large animations will take a lot of memory. (bug 143046 is
looking at ways to do it 8bits).
However this is not an official leak, as the memory is released when the image
is released. 
285872 prevents memory fragmentation caused by the GIF decoder during the
loading of a 2MB gif image, by removing the upto 1000 alloc/reallocs caused by
the dynamic gathering buffer. While the decoded image is still large, it will
cause less memory pressure...
Depends on: 285872
I can reproduce this using this graphic:
http://facs.scripps.edu/surf/images/maps/ganimswp.gif

while loading the cpu goes to 100% and moz becomes non-responsive.
mem gradually increases. The cpu/responsiveness returns after roughly 30 seconds. the memory stays increased.

the memory is less of an issue to me, the fact that moz crashes for a period of time is a big problem.

This is a CRITICAL issue. A BLOCKER even.
I understand your feelings about crashing.
But the fact that the image you provided does indeed uses a lot of memory (according to about:cache about 21MB), is not the cause of any crashes.
In my FF1.5 version (with lots of themes and extensions) on an average Thinkpad, it loads fasts, doesn't block FF, and displays happily...

The image is 29 frames at 452x551, resulting in 29*452*551*3bytes = 21MB of internal image data. (note the compressed image is 1.4MB, which also tells that the uncompressed image will take a lot of memory anyway).
There are other bugs related to optimize the memory usage, for example:
Bug 143046 is about not using 3 bytes per pixel, but just the original 8bits.
I've just reproduced this on Deer Park Alpha 2 (1.6a1)

ps. should be BLOCKING
blocking what?  don't load 2mb animated gifs if you don't want to use lots of memory.  there are much better formats for video or long animations.
as I've previously mentioned, it is not the memory issue that worries me. firefox crashes.

my current workaround is to use internet explorer to browse problem animations, which hopefully isn't a long term solution.

i do not create the animations, however their information is extremely important to me. i do not have to choice of a different format, only what browser i use to display them.

thank you for your misinformed irrelevant comment.
Paul,

If that image does indeed crashes FF, please create 'talkbalk' reports.
At least produce a reproducable testcase so that the problem (if any) can be explored and solved. Right now, the image you have provided works perfectly in all my FF and Seamonkey editions... In fact, even much larger versions also work without any crashes.
my lingo was missleading .. by crash i mean hang. it returns after a period of time, usually 30sec - 1min .. therefore talkback is not helpful.

i have reproduced this on both of the windows computers i use (one xp-FF1.5, one 2k-Deer Park Alpha 2),
Attached image graph of cpu usage — 
for those of you who don't think this is a problem: the peak of the cpu graph is 1.5 gigs. the first slight blip of cpu is firefox starting up. firefox crashed where the memory metre plumets. from where the cpu leaps to 100% to where ff crashes was roughly five minutes.

i did not get a talkback dialog.

BLOCKING!!!!
also, the memory slope only started when the image FINISHED downloading and therefore has nothing to do with unpacking the compressed image as it had already fully displayed once.
just upgraded to 1.5.0.1 and it still happens. this didn't happen pre 1.5 tho.
I got this problem with the last firefox version ( 1.5.0.1 or 1.8.0.1 it depends... I still don't understand the way of numbering versions :( ). The ram consumption grows to more than 700 Mo (out of 1,5Go) and the cpu usage keeps around 80 100 % while loading http://facs.scripps.edu/surf/images/euranim.gif

even if I open it in a single tab, right after starting firefox and in safe mode (no extension loaded) what is strange is that when doing exactly the same with mozilla there's absolutely no problem : the max memory usage is only 35Mo and cpu usage about 5 or 10 % (with many extensions loaded)

So if there's a problem with Firefox picture rendering, why not use the mozilla version ?
i think we are talking to ourselves .. maybe if we create enough bug spam....? ;)
Another precision, when opening http://facs.scripps.edu/surf/images/euranim.gif with mozilla suite 1.7.13, there's no problem : memory usage isn't more than 45 Mo (while having email client opened) and CPU usage is of 1% max. So the bug shouldn't be in Core / Images GFX, which is common to Firefox and Mozilla, this problem is specific to Firefox
still happening:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
still happening:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
(In reply to comment #32)
> still happening:
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728
> Firefox/1.5.0.6
> 

Yes, as you can see from the bugs status, no need to for "still happening" spam comments
I've just noticed that this only occurs when you load the image from it's url (ie http://www.server.dom/image.gif)

However, if the image is embedded (eg in an html file) it will load fine without any memory or cpu issues.

So it is obviously not an issue with image unpacking etc.
Try this one :
http://www.bismutnetwork.com/10Music/Crisis/soundfont3.0.php
My RAM up to 220Mo
Alouette
I haven't anymore problems with this picture http://www.lajollasurf.org/images/euranim.gif
with firefox last release :
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
*** Bug 318965 has been marked as a duplicate of this bug. ***
i think this is fixed in 2.0?
Paul in comment #18:
> I can reproduce this using this graphic:
> http://facs.scripps.edu/surf/images/maps/ganimswp.gif

WFM on FF trunk and low CPU, though some modest memory consumption  (10mb)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060510 Minefield/3.0a1
also http://facs.scripps.edu/surf/images/euranim.gif

SM trunk has same results


(In reply to comment #35)
> Try this one :
> http://www.bismutnetwork.com/10Music/Crisis/soundfont3.0.php
> My RAM up to 220Mo
> Alouette

this is far too complex for an example - it has flash images.  Flash has it own class of problems in the players and in FF, i.e. it is a *different* problem.


One most be careful in posting examples - please test and pick it apart so it is limited to one issue.

Suggest this be closed as a dupe to another animated gif bug for those interested in animated gif issues to pursue the problem in a more modern bug.  Plus it's true that no one's watching this old bug.
QA Contact: tpreston
Assignee: pavlov → nobody
Removing MLK, as it is actually not a leak, just exorbitant memory usage to store the image data (4 bytes times width times height times number of frames results in very large numbers for animated GIF images...)
(bug 143046 is looking at ways to do store such images a 8bit palette images).
Keywords: mlk
A totally other approach is to not keep all the frames in memory (only the first frame and a few around the current displayed frame). 
For AGIF's and animation pref set to 'no animation', only the first frame is needed.
For AGIF's with only one loop, we only need the frames once, so they can be discarded quickly.
But for AGIF's with multiple loops, we can only discard 'old' frames if there is a way to restart the image decoding from the data source to reconstruct the frames on the fly. Image decoding itself is fast enough for this purpose.

We only need then to:
1. make imgContainer discard 'old' frames (when total size is large than a threshold)
2. make a way to restart the image decoding when the animation loops around to reconstruct discarded frames (this is only needed when indeed frames were discarded (see 1)).
Can confirm the bug on this image
http://vectormagic.stanford.edu/comparisons/rotational_invariance.gif
from
http://vectormagic.stanford.edu/vectorize/comparisons

This occurs in both the Linux and Windows builds of Firefox 2.0.0.8, and both when the image is in a document or loaded separately.

Is it just me, or is 6 years a bit long for a bug?
Please look at bug 143046 for the memory usage fix for gif animations, so don't add any more comments about this or that GIF uses lot of memory to this bug.

Please put your votes on bug 143046. It has a valid patch and only needs reviews and approvals (which will be faster if there are many votes).
Based on testing with current build with bug 143046 fixed, and the three links provided in comment #40, firefox now grows to 140MB (from ±70MB), and shrinks back to 70MB after closing those tabs.

So, this item can now be closed, marking as 'FIXED by bug 143046'
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: