65016 - Crash on loading an animated GIF

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Koike Kazuhiko]

Crashes on loading an animated GIF.

This is a recent and serious regression!

Build: 2001011004/Win2k

Comment 1

[Koike Kazuhiko]

Attachment: Testcase(Animated GIF file)

Comment 2

[Koike Kazuhiko]

2001011020/Win98 doesn't crash.

Comment 3

[Koike Kazuhiko]

2001011020/Win98 crashes if I add

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

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

Comment 4

[Akkana Peck]

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

[Sean Richardson]

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
http://www.cnn.com/ 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

[NilsE]

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 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22329 loaded
successfully
###!!! 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
nsCSSFrameConstructor.cpp:10248
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
nsFrameManager.cpp:915
#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
nsEventQueue.cpp:356
#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/libglib-1.2.so.0
#9  0x40620186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#10 0x40620751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#11 0x406208f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#12 0x407065b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#13 0x408fb8da in nsAppShell::Run (this=0x8064440) at nsAppShell.cpp:350
#14 0x405dee74 in nsAppShellService::Run (this=0x80a0690) at
nsAppShellService.cpp:407
#15 0x0805095e in main1 (argc=1, argv=0xbffff014, nativeApp=0x0) at
nsAppRunner.cpp:1030
#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
../sysdeps/generic/libc-start.c:92
(gdb) 

Comment 7

[Kurt Weinschenker]

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

Comment 8

[NilsE]

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

[Akkana Peck]

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.

Comment 10

[tor]

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

Comment 11

[NilsE]

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
"fixed".

Comment 12

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 13

[Terri Preston]

The new imagelib appeared to have fixed this crashed
Verified this on W2k build 2001040304, linux build 2001040305 and mac build
2001040213
  

Comment 14

[NilsE]

> 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

[Terri Preston]

Verified w2k build 2001022404
Verified mac build 2001052405