Crashes on loading an animated GIF. This is a recent and serious regression! Build: 2001011004/Win2k

2001011020/Win98 doesn't crash.

2001011020/Win98 crashes if I add user_pref("image.animation_mode", "none"); in prefs.js. See bug 17686 for this setting.

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?

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.

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)

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

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

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.

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

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

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

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

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

Verified w2k build 2001022404 Verified mac build 2001052405