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.
This is a severe bug on solaris and linux, it take large mem and lead to machine down. email@example.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: 143046
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.
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),
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. 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 184.108.40.206 and it still happens. this didn't happen pre 1.5 tho.
Created attachment 217826 [details] memory and cpu usage with firefox in safe mode I got this problem with the last firefox version ( 220.127.116.11 or 18.104.22.168 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:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199
still happening: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060728 Firefox/184.108.40.206
(In reply to comment #32) > still happening: > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060728 > Firefox/18.104.22.168 > 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:22.214.171.124) Gecko/20060728 Firefox/126.96.36.199
*** Bug 318965 has been marked as a duplicate of this bug. ***
i think this is fixed in 2.0?
URL is dead, updating
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
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).
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 188.8.131.52, 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
Last Resolved: 11 years ago
Resolution: --- → FIXED
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.