Crash on loading an animated GIF

VERIFIED FIXED in mozilla0.9.1



17 years ago
13 years ago


(Reporter: Koike Kazuhiko, Assigned: Stuart Parmenter)


({crash, regression})

Windows 2000
crash, regression

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
Crashes on loading an animated GIF.

This is a recent and serious regression!

Build: 2001011004/Win2k


17 years ago
Severity: normal → critical
Keywords: crash

Comment 1

17 years ago
Created attachment 22329 [details]
Testcase(Animated GIF file)

Comment 2

17 years ago
2001011020/Win98 doesn't crash.

Comment 3

17 years ago
2001011020/Win98 crashes if I add

user_pref("image.animation_mode", "none");

in prefs.js. See bug 17686 for this setting.

Comment 4

17 years ago
I never see the crash.  If I set animationMode to none, I see each image start
to load, then sometimes the load aborts, the page reflows (apparently even
though we loaded enough to get the dimensions of the image, they're then set to
zero once we discover it's animated and abort the load?)  Other times, the image
stays loaded showing the first frame (which is what I expected to happen -- the
first frame, or at least as much as we already had at the point when we
discovered it was animated and stopped loading anything further).

Nobody's gotten a stack trace yet, but we do have the last element in it:

nsCSSFrameConstructor:10248, which is aFrame->GetParent(&parentFrame);

aFrame isn't null, so a null check here wouldn't help, but perhaps aFrame has
been deleted and the callback wasn't unregistered?

Comment 5

17 years ago
Quoting from bug 17686, "Preference for animated image display (GIF89a, MNG)"

  ------- Additional Comments From Nils 2001-01-10 11:09 -------

  Now that the feature is in, I tried it with Build 2001011008 (Linux 2.2).
  animation_mode "once" works like a charm, but if I set it to "none" I get
  frequent crashes on pages that use animated GIFs. Try setting it to "none" and
  visit Slashdot. It doesn't always crash - does it depend on the GIF?

  ------- Additional Comments From Nils 2001-01-11 04:06 -------

  As written before, force reloading a page when animation mode is "none" 
  crashes mozilla for me after (on average) 5-7 reloads (100% reproducible).   
  Tried with CVS snapshot from 9 a.m. GMT+1, Jan 11, 2001 on RedHat 6.2. 

I attempted to reproduce with 2001-01-11-04-talkback on WinNT 4.0;
no luck getting a crash reloading slashdot, but after 5 reloads of I got a crash and a talkback incident: TB24461456W
Another incident ID: TB24484733G

On the other hand, every attempt to reload the image in the attachment to this
bug resulted in the same behaviour reported by Akkana 2001-01-11 14:51 --
bug 65175, "amimated image replaced by ALT text: animation_mode none" filed
for that.

Comment 6

17 years ago
Ok, here you go. Tested with recent CVS (9:20 a.m. GMT+1, Jan 12) on
intel/RedHat 6.2. I loaded Kazuhiko's test image and mozilla crashed on first
load. Here's what gdb says to it (BTW, I can't seem to make attachments, I
always get a message that my attached file was empty):

Enabling Quirk StyleSheet
Document loaded
###!!! ASSERTION: frame already has posted event:
'!*FindPostedEventFor(aFrame)', file nsFrameManager.cpp, line 963

###!!! ASSERTION: frame already has posted event:
'!*FindPostedEventFor(aFrame)', file nsFrameManager.cpp, line 963
###!!! Break: at file nsFrameManager.cpp, line 963
WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line 410

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
0x41266771 in nsCSSFrameConstructor::CantRenderReplacedElement (this=0x86a94f8,
aPresShell=0x85736a8, aPresContext=0x8543d60, aFrame=0x85c3920) at
Current language:  auto; currently c++
(gdb) where
#0  0x41266771 in nsCSSFrameConstructor::CantRenderReplacedElement
(this=0x86a94f8, aPresShell=0x85736a8, aPresContext=0x8543d60, aFrame=0x85c3920)
at nsCSSFrameConstructor.cpp:10248
#1  0x41421978 in StyleSetImpl::CantRenderReplacedElement (this=0x8507d80,
aPresContext=0x8543d60, aFrame=0x85c3920) at nsStyleSet.cpp:1301
#2  0x410e77ab in FrameManager::HandlePLEvent (aEvent=0x856b700) at
#3  0x400fb16e in PL_HandleEvent (self=0x856b700) at plevent.c:576
#4  0x400fa976 in PL_ProcessPendingEvents (self=0x8099c08) at plevent.c:509
#5  0x400fc7fc in nsEventQueueImpl::ProcessPendingEvents (this=0x8099be0) at
#6  0x408fb913 in event_processor_callback (data=0x8099be0, source=7,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#7  0x408fbb15 in our_gdk_io_invoke (source=0x81d81e8, condition=G_IO_IN,
data=0x81edfe8) at nsAppShell.cpp:58
#8  0x4061eaca in g_io_unix_dispatch () from /usr/lib/
#9  0x40620186 in g_main_dispatch () from /usr/lib/
#10 0x40620751 in g_main_iterate () from /usr/lib/
#11 0x406208f1 in g_main_run () from /usr/lib/
#12 0x407065b9 in gtk_main () from /usr/lib/
#13 0x408fb8da in nsAppShell::Run (this=0x8064440) at nsAppShell.cpp:350
#14 0x405dee74 in nsAppShellService::Run (this=0x80a0690) at
#15 0x0805095e in main1 (argc=1, argv=0xbffff014, nativeApp=0x0) at
#16 0x080513ff in main (argc=1, argv=0xbffff014) at nsAppRunner.cpp:1298
#17 0x403059cb in __libc_start_main (main=0x80512fc <main>, argc=1,
argv=0xbffff014, init=0x804b4a4 <_init>, fini=0x805c1a0 <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff00c) at

Comment 7

17 years ago
Apparently a Windows/Linux bug only, Mozilla Mac-Trunk build 2001013004 seemed
to work fine with testcase.

iMac DV, Mac OS 9.0.4, MRJ 2.2.4, carbon lib 1.2


17 years ago
Keywords: mozilla0.8, nsbeta1, regression

Comment 8

17 years ago
Citing from bug 69405:

  ------- Additional Comments From Blake Ross 2001-02-19 15:08 -------
  (Just pointing out that I have the UI for 64831 working, but tor expressed
  interest in waiting until the "never" crasher is fixed).

I agree. As I'm interested in this, I've been trying myself, but as the problem
is connected to the event structure (for which you need more time than I have
right now to learn how it works), it appears that someone with in-depth
knowledge of this should have a look. In the end, it might be only a small
glitch ...

Comment 9

17 years ago
Libimg is being completely rewritten.  Supposedly, the new one will land within
a week or two.  The event structure and all the code will be different, so I
wouldn't spend much energy trying to debug sporadic crashes in the current netlib.


17 years ago
Keywords: mozilla0.9


17 years ago
Keywords: mozilla0.8.1


17 years ago
Keywords: mozilla0.8


17 years ago
Target Milestone: --- → mozilla0.9.1

Comment 10

17 years ago
*** Bug 71300 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
Just tried it with CVS build (ID 2001031212, UTC time) on x86/RedHat 6.2 with
the new imglib (--enable-libpr0n) and the crash seems to be gone. If the new lib
goes into the main build and others confirm, this bug can probably be marked

Comment 12

17 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov

Comment 13

17 years ago
The new imagelib appeared to have fixed this crashed
Verified this on W2k build 2001040304, linux build 2001040305 and mac build
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
> The new imagelib appeared to have fixed this crashed

"Fixed" is good - the feature disappeared. :-( See bug 74169. Regression.
But yes, the crash is gone.

Comment 15

16 years ago
Verified w2k build 2001022404
Verified mac build 2001052405
You need to log in before you can comment on or make changes to this bug.