huge memory use loading a 2M animated GIF

RESOLVED FIXED in mozilla1.1beta


Core Graveyard
Image: Painting
17 years ago
9 years ago


(Reporter: Jeremy M. Dolan, Unassigned)


({memory-footprint, perf})

memory-footprint, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
Allocating 108 meg to load this 2M image. Loading it via file:, and it's

Linux 095.

Comment 1

17 years ago
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

Comment 2

17 years ago
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*

4 meg animated GIF.


17 years ago
Target Milestone: --- → mozilla1.1


17 years ago
Blocks: 119597


17 years ago
Keywords: footprint

Comment 3

17 years ago
   This is a severe bug on solaris and linux, it take large mem and lead to 
machine down.


16 years ago
Component: ImageLib → Image: GFX
Target Milestone: mozilla1.1alpha → mozilla1.1beta
I just tried 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.

Comment 5

16 years ago
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

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, has almost identical
behaviour as IE. It needed 143 megs of ram, and hardly any CPU usage.
OS: Linux → All
Hardware: PC → All

Comment 6

16 years ago
*** Bug 158305 has been marked as a duplicate of this bug. ***

Comment 7

16 years ago
I have seen this bug consistently as well with Mozilla 1.1:

Comment 8

16 years ago

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.

Comment 9

16 years ago
I see this bug with Chimera (on Mac OS X 10.2.3) also when viewing animations
referenced at

Comment 10

16 years ago
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. :-(

Comment 11

16 years ago
I think this should be reduced greatly (if not fixed) with the fix for bug 143046.
Depends on: 143046

Comment 12

16 years ago
I loaded the following image in Mozilla 1.3
(, 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
        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 *)
            imgRequest::OnDataAvailable(nsIRequest *,nsISupports
*,nsIInputStream *,UINT,UINT) [imgRequest.cpp:783]

Comment 13

14 years ago
*** Bug 201707 has been marked as a duplicate of this bug. ***

Comment 14

14 years ago
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.

Comment 15

14 years ago
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. 


14 years ago
Depends on: 274391

Comment 16

14 years ago
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. 

Comment 17

13 years ago
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

Comment 18

13 years ago
I can reproduce this using this graphic:

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.

Comment 19

13 years ago
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.

Comment 20

13 years ago
I've just reproduced this on Deer Park Alpha 2 (1.6a1)

ps. should be BLOCKING

Comment 21

13 years ago
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.

Comment 22

13 years ago
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.

Comment 23

13 years ago

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.

Comment 24

13 years ago
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), 

Comment 25

13 years ago
Created attachment 210339 [details]
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.


Comment 26

13 years ago
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.

Comment 27

13 years ago
just upgraded to and it still happens. this didn't happen pre 1.5 tho.

Comment 28

12 years ago
Created attachment 217826 [details]
memory and cpu usage with firefox in safe mode

I got this problem with the last firefox version ( or 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

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 ?

Comment 29

12 years ago
i think we are talking to ourselves .. maybe if we create enough bug spam....? ;)

Comment 30

12 years ago
Another precision, when opening 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

Comment 31

12 years ago
still happening:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060508 Firefox/

Comment 32

12 years ago
still happening:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060728 Firefox/

Comment 33

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

Yes, as you can see from the bugs status, no need to for "still happening" spam comments

Comment 34

12 years ago
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.

Comment 35

12 years ago
Try this one :
My RAM up to 220Mo

Comment 36

12 years ago
I haven't anymore problems with this picture
with firefox last release :
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20060728 Firefox/

Comment 37

12 years ago
*** Bug 318965 has been marked as a duplicate of this bug. ***

Comment 38

12 years ago
i think this is fixed in 2.0?

Comment 40

12 years ago
Paul in comment #18:
> I can reproduce this using this graphic:

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

SM trunk has same results

(In reply to comment #35)
> Try this one :
> 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
QA Contact: image.gfx
Duplicate of this bug: 126445


11 years ago
Assignee: pavlov → nobody

Comment 42

11 years ago
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

Comment 43

11 years ago
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)).


11 years ago
Duplicate of this bug: 198043


11 years ago
Duplicate of this bug: 250290

Comment 46

11 years ago
Can confirm the bug on this image

This occurs in both the Linux and Windows builds of Firefox, 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?

Comment 47

11 years ago
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).

Comment 48

11 years ago
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'
Last Resolved: 11 years ago
Resolution: --- → FIXED


9 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.