Closed Bug 126445 Opened 23 years ago Closed 17 years ago

large animated image uses too much memory

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 105370

People

(Reporter: steve, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: memory-footprint, perf) 

When I visit the above image, it crashes Mozilla. I first found this on 0.9.6,
where I had java and flash plugins and talkback. Oddly, Talkback didn't come up
after it crashed, even though it has many times before on the same build. I am
now running 0.9.8 without any plugins but still with talkback, and I get the
same thing.

I'm running a base RedHat 6.2 linux with a moderate amount of upgrades.
The GIF is ~871 kilobytes, in case people are wondering.

Worksforme on Windows 98, Build ID: 2002021803, (0.9.8+). It does take a _long_
time to download and start animating, though. 

Are you sure you waited long enough to let Mozilla start displaying the image?
Would you say that Mozilla crashed, meaning that the Mozilla program stopped and
the windows disappeared, forcing you to restart it? Or did it hang, forcing you
to kill the process manually? Thanks.
Component: Browser-General → ImageLib
wfm using build 2002021906 on Linux.
Reporter: Please always use severity level "critical" for crashes.
WFM. Build ID: 2002 02 15 03. Windows 2000.
Mozilla crashed, as in the window disappeared, the process no longer showed up
in ps, and the shell where I started it printed another prompt. Without asking
if I wanted to debug the problem, as it usually does when it crashes.

My machine has 512MB of RAM, without about 256MB free.

I tried it again while running 'vmstat 1' at the same time. This time, it
worked. It came up, and the animation was very slow initially, but it sped up to
a decent speed. Then, about 30 seconds into it, it crashed in the same way (no
talkback, no debug).

Aha! /var/log/messages shows that the kernel killed it. Which could explain the
lack of talkback etc. I should've thought of that and checked earlier.

The vmstat output shows that my memory dropped dangerously low while it was
loading. I stopped the vmstat after it started to display, so I don't know if
the free memory dropped to nothing. While the image loaded, it dropped from 18MB
down to 2MB, and buffers shrank from 58MB to 19MB.

I am running a 2.4.17 kernel with only 128MB of swap for 512MB physical RAM.

Looks to me like a kernel problem, not a Mozilla one, although perhaps ImageLib
shouldn't be burning so much memory on it.

Here's the end of /var/log/messages:

Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21597 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21651 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21652 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21653 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21654 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21655 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21656 (java). 
Feb 25 12:59:09 foxglove kernel: Out of Memory: Killed process 21657 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28148 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28201 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28202 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28203 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28204 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28205 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28206 (java). 
Feb 25 12:59:50 foxglove kernel: Out of Memory: Killed process 28207 (java). 
Feb 25 12:59:58 foxglove kernel: Out of Memory: Killed process 32392 (mozilla-bin). 
Feb 25 12:59:58 foxglove kernel: Out of Memory: Killed process 32394 (mozilla-bin). 
Feb 25 12:59:58 foxglove kernel: Out of Memory: Killed process 32395 (mozilla-bin). 
Feb 25 12:59:58 foxglove kernel: Out of Memory: Killed process 32396 (mozilla-bin).
Maybe you can fix that bug by tweaking your Linux system? Not sure.

The real problem here seems to be excessive memory use. Should we resummarize 
the bug to indicate that? 
Renaming and leaving it noncritical is certainly fine with me.

I probably could see it by adding more swap, but I have no burning need to view
the gif in the first place. So I'm happy either way.

Thanks!

Old Summary: large animated image crashes browser, no talkback

New Summary: large animated image uses too much memory


Actual Behavior: Mozilla uses an excessive amount of memory to display this
animated GIF, perhaps only on the Linux platform

Expected Behavior: Mozilla displays the image more efficiently
Blocks: 119597
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: footprint
Is this is an issue with libpr0n? libimg decodes one frame at a time and
displays it; if it's a really big image you just see it once. libpr0n waits
until it reads the entire animated gif, then decodes and displays it. The
libpr0n behavior is bad if decoding the entire animated gif uses up all your
memory or if the animated gif is generated "on the fly" and you have to wait for
the entire thing to get there before you see the second frame.

This gif 
http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP/.EMC/.CMB/.GLOBAL/.weekly/figviewer.html?my.help=&map.T.plotvalue=4+Nov+1981+to+30+Aug+2000&map.Y.units=degree_north&map.Y.plotlast=90N&map.url=a-+.ssta+-a+X+Y+fig-+colors+land+-fig&map.domain=+%7B+%2FT+3.+6877.+plotrange+X+30.+390.+plotrange+%7D&map.domainparam=+%2Fplotaxislength+432+psdef+%2Fplotborder+72+psdef+%2FXOVY+null+psdef&map.zoom=Zoom&map.Y.plotfirst=90S&map.X.plotfirst=30E&map.X.units=degree_east&map.X.modulus=360&map.X.plotlast=30E&map.ssta.plotfirst=-4.2&map.ssta.units=degree_Celsius&map.ssta.plotlast=4.2&map.newurl.grid0=X&map.newurl.grid1=Y&map.newurl.land=draw+land&map.newurl.vars.0=.ssta&map.newurl.plot=colors&map.plotaxislength=432&map.plotborder=72&map.fnt=Helvetica&map.fntsze=12&map.color_smoothing=auto&map.antialias=on&map.XOVY=auto&map.iftime=25&map.mftime=25&map.fftime=200&my.help=more+options
is about 40M and causes my mozilla memory usage under linux to be about 458M. I
happen to have enough memory, but it takes forever to see the second frame.
Konquerer decodes the frames as they come. I wish I didn't have to say that
Mozilla is a great browser, except for animated gifs.
Really changing summary. 

Comment 10 is interesting. Would you say that Mozilla should re-render each 
frame? Or should we say something like, "if the animated GIF is 1 MB or bigger, 
then render frame by frame, otherwise use existing behavior"?
Summary: large animated image crashes browser, no talkback → large animated image uses too much memory
I see two points. First, benefits from rendering the entire gif should
be balanced against memory cost; this is hardware dependent. I'm perfectly happy
with mozilla performance for the xebot005.gif testcase; I have lots of memory.
Second, regardless of memory cost, performance looks awful if the entire gif is,
for any reason (e.g., size or network), slow to load.

So, at least you should go frame by frame if doing the entire thing will make
your system swap. Addionally, I'd like to be able to set the limit for deciding
the rendering behavior or say always go frame by frame in preferences. Just
because I have memory, I may not want to wait for the whole thing to load. 

Of course, all of this supposes there is a good reason to render the entire gif
at one time. Caching?

Could this bug be causing other problems in tracking bug 119597? If so, it
should be fixed soon. For now, though, I'll nominate it for Mozilla 1.1.
Keywords: mozilla1.1
CC'ing image/etc people
This is really a stuart/tor issue I think.  Should affect all platforms.  Also
highlights that we don't decode on-the-fly while others do.
Keywords: perf
OS: Linux → All
Hardware: PC → All
I strongly believe that decoding everything once is the right way to do things,
and if we stored GIFs as paletted images, we'd take up 1/3 of the space we
currently take up.
Keywords: mozilla1.1 → mozilla1.0, nsbeta1
Blocks: 124608
Stuart , isn't storing GIF's as paletted images bug #143046 ?
related (dupe ?): bug 105370.
reassigning
Assignee: asa → pavlov
QA Contact: doron → tpreston
Keywords: mozilla1.0
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 213391 has been marked as a duplicate of this bug. ***
In response to comment #10:
Current editions of Firefox and Mozilla (March 2005) can handle the 
enormous animated gif provided in that example, and start display next frames
as soon as they load. 

Talking about not keeping in memory all the frames may be an option for such
large animated images, providing they don't loop (in other words only display
each frame once). In such a case we could destroy each frame (the 24bit internal
RGB image) after having displayed it, instead of keeping it around.
But at least when the user preference for image looping says 'Don't loop' 'Loop
once' only we could destroy each frame *after* having displayed it. (but not the
current display frame). 

So we could destroy old frames when the user pref says loop once or never, and
as soon as LoopCount is set to zero (=loop once). We then also need to
invalidate the image cache entry (as then the image is then partly destroyed).

In summary, this is not probably worth the trouble this can cause...
*** Bug 178809 has been marked as a duplicate of this bug. ***
This is really a dup of Bug 105370.
Will the votes get moved over if it gets marked as such?
(In reply to comment #23)
> This is really a dup of Bug 105370.
> Will the votes get moved over if it gets marked as such?

nope.
but that shouldn't stop someone from duping it - for 3 votes - plus the voters get notified if they're bugzilla prefs are set so.


Allow me then.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
No longer blocks: 119597, 124608
You need to log in before you can comment on or make changes to this bug.