609499 - ABORT: Can't be done decoding if we're mid-frame!: '!mInFrame'

Status: VERIFIED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Bob Clary [:bc] (inactive)]

1. <http://www.astonmartin.com/configurator/db9coupe.asp?td=UL%2526x=14%2526y=10>
2. ABORT 2.0.0 windows/linux/mac

example crash report for mac: attachment 487956 [details]

ditto: <http://www.astonmartin.com/configurator/db9volante.asp?td=UL%2526x=6%2526y=8>

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: test image

Comment 2

[Bob Clary [:bc] (inactive)]

FYI, I've seen this on the following domains during crash testing:

billboard.fusionchicago.com, darkwing.uoregon.edu, francite.net, home.austarnet.com.au, www.astonmartin.com, www.inspirationalsayingss.com, ziggo-gebruikers.nl

Comment 3

[Bob Clary [:bc] (inactive)]

This continues to be a common Abort during crash automation testing. It can cause issues for automated testing by potentially hiding other crashes.

If it isn't important enough to fix, then perhaps it should be a non-fatal ASSERTION rather than an Abort?

Comment 4

[Carsten Book [:Tomcat]]

also running into this during the topsite test for firefox 5 on mac 10.5

###!!! ABORT: Can't be done decoding if we're mid-frame!: '!mInFrame', file /work/mozilla/builds/firefox5/mozilla-beta/modules/libpr0n/src/Decoder.cpp, line 265

http://www.inspirationalquotes4u.com: EXIT STATUS: CRASHED signal 10 SIGBUS (262.444834 seconds)

Process:         firefox-bin [68855]
Path:            /work/mozilla/builds/firefox5/mozilla-beta/firefox-debug/dist/FirefoxDebug.app/Contents/MacOS/firefox-bin
Identifier:      org.mozilla.firefoxdebug
Version:         5.0 (5.0)
Code Type:       X86 (Native)
Parent Process:  Python [68854]

Date/Time:       2011-05-24 01:59:24.078 -0700
OS Version:      Mac OS X 10.5.8 (9L31a)
Report Version:  6
Anonymous UUID:  B2E3E6EE-C548-4067-897B-2D76DED446CB

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   libmozalloc.dylib             	0x0001af43 __ZL14TouchBadMemoryv + 17
1   libmozalloc.dylib             	0x0001af9f mozalloc_abort(char const*) + 69
2   XUL                           	0x06553661 __ZL5AbortPKc + 17
3   XUL                           	0x06553bb5 NS_DebugBreak_P + 609 (nsDebugImpl.cpp:346)
4   XUL                           	0x0503b027 mozilla::imagelib::Decoder::PostDecodeDone() + 141 (Decoder.cpp:266)
5   XUL                           	0x05070cc1 mozilla::imagelib::nsGIFDecoder2::WriteInternal(char const*, unsigned int) + 3663 (nsGIFDecoder2.cpp:1056)
6   XUL                           	0x0503af93 mozilla::imagelib::Decoder::Write(char const*, unsigned int) + 125 (Decoder.cpp:104)
7   XUL                           	0x0503e175 mozilla::imagelib::RasterImage::WriteToDecoder(char const*, unsigned int) + 235 (RasterImage.cpp:2274)
8   XUL                           	0x0503e39e mozilla::imagelib::RasterImage::DecodeSomeData(unsigned int) + 262 (RasterImage.cpp:2580)
9   XUL                           	0x0503e56c mozilla::imagelib::imgDecodeWorker::Run() + 442 (RasterImage.cpp:2696)
10  XUL                           	0x0503ea8e mozilla::imagelib::RasterImage::AddSourceData(char const*, unsigned int) + 780 (RasterImage.cpp:1265)
11  XUL                           	0x0503ec0d mozilla::imagelib::RasterImage::WriteToRasterImage(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) + 37 (RasterImage.cpp:2776)
12  XUL                           	0x0650cdcb nsInputStreamTee::WriteSegmentFun(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) + 71 (nsInputStreamTee.cpp:223)
13  XUL                           	0x06513829 nsPipeInputStream::ReadSegments(unsigned int (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) + 335 (nsPipe3.cpp:798)
14  XUL                           	0x0650c2ac nsInputStreamTee::ReadSegments(unsigned int (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) + 178 (nsInputStreamTee.cpp:276)
15  XUL                           	0x050628f6 imgRequest::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 3674 (imgRequest.cpp:1152)
16  XUL                           	0x05051065 ProxyListener::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 101 (imgLoader.cpp:2013)
17  XUL                           	0x04e78428 nsStreamListenerTee::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 752 (nsStreamListenerTee.cpp:111)
18  XUL                           	0x04f2bab7 nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) + 815 (nsHttpChannel.cpp:4198)
19  XUL                           	0x04e40e05 nsInputStreamPump::OnStateTransfer() + 777 (nsInputStreamPump.cpp:510)
20  XUL                           	0x04e4131c nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) + 138 (nsInputStreamPump.cpp:400)
21  XUL                           	0x06515756 nsInputStreamReadyEvent::Run() + 100 (nsStreamUtils.cpp:115)
22  XUL                           	0x06542488 nsThread::ProcessNextEvent(int, int*) + 910 (nsThread.cpp:618)
23  XUL                           	0x064ca006 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) + 146
24  XUL                           	0x0622b46d nsBaseAppShell::NativeEventCallback() + 181 (nsBaseAppShell.cpp:131)
25  XUL                           	0x061d8351 nsAppShell::ProcessGeckoEvents(void*) + 521 (nsAppShell.mm:400)
26  com.apple.CoreFoundation      	0x91e7c3c5 CFRunLoopRunSpecific + 3141
27  com.apple.CoreFoundation      	0x91e7caa8 CFRunLoopRunInMode + 88
28  com.apple.HIToolbox           	0x952e22ac RunCurrentEventLoopInMode + 283
29  com.apple.HIToolbox           	0x952e1ffe ReceiveNextEventCommon + 175
30  com.apple.HIToolbox           	0x952e1f39 BlockUntilNextEventMatchingListInMode + 106
31  com.apple.AppKit              	0x927ec6d5 _DPSNextEvent + 657
32  com.apple.AppKit              	0x927ebf88 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
33  com.apple.AppKit              	0x927e4f9f -[NSApplication run] + 795
34  XUL                           	0x061d70b3 nsAppShell::Run() + 291 (nsAppShell.mm:746)
35  XUL                           	0x05f20cde nsAppStartup::Run() + 148 (nsAppStartup.cpp:218)
36  XUL                           	0x04e046d2 XRE_main + 10254 (nsAppRunner.cpp:3754)
37  org.mozilla.firefoxdebug      	0x00002812 main + 714 (nsBrowserApp.cpp:158)
38  org.mozilla.firefoxdebug      	0x00002492 start + 54

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x0001af66  ecx: 0x0001af3d  edx: 0x00000000
  edi: 0x0004a401  esi: 0x00000000  ebp: 0xbfff9318  esp: 0xbfff9310
   ss: 0x0000001f  efl: 0x00010282  eip: 0x0001af43   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x00000000

Comment 5

[Daniel Veditz [:dveditz]]

This crash is common enough to be interfering with automated testing, which potentially masks finding crashes that might be exploitable. A fatal runtime abort implies a serious problem that is intended never to happen and that needs to be fixed ASAP. Needs to be fixed or downgraded to an assert with some runtime handling for the error.

Comment 6

[Bobby Holley (:bholley)]

I'm not active until August. Reassigning to joe.

Comment 7

[Daniel Veditz [:dveditz]]

may not rate landing on the beta branch unless it's a topcrash, but Fx6 for sure.

Comment 8

[Asa Dotzler [:asa]]

Firefox 6 is deep into Beta and there's no action here. Is this something we care about for 6? If so, who can work on it? JP, can you help us find someone for this?

Comment 9

[Joe Drew (not getting mail)]

I'm not clear on why this is tracking firefox 6. This is a debug-only assertion failure.

Also, I'm going to work on it next.

Comment 10

[Joe Drew (not getting mail)]

Attachment: Some invalid GIF files don't terminate their LZW data with a 0-length block. Handle them better by handling them less specially.

Comment 11

[Joe Drew (not getting mail)]

Attachment: Crashtest for GIFs that abruptly terminate their LZW data.

Comment 12

[Johnny Stenback (:jst)]

Joe, seems this is ready to land, or is that not the case?

Comment 13

[Joe Drew (not getting mail)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/b38381eb91b8
http://hg.mozilla.org/integration/mozilla-inbound/rev/67044ea27b53

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

http://hg.mozilla.org/mozilla-central/rev/67044ea27b53
http://hg.mozilla.org/mozilla-central/rev/b38381eb91b8

Comment 15

[Bob Clary [:bc] (inactive)]

verified. not seen in automation since 8/4. Thanks!

Comment 16

[Jeff Muizelaar [:jrmuizel]]

This has been backed out because of bug 677044

Comment 17

[Bob Clary [:bc] (inactive)]

Joe, I keep seeing this on all branches on all operating systems in crash automation. It is a very frequent abort and is a pita. Can we try again or at least turn this into a non fatal assertion?

Comment 18

[Bob Clary [:bc] (inactive)]

fyi, still reproducible on 94 recent crash urls including the testcase.

Comment 19

[Chris Peterson [:cpeterson]]

The attached testcase WFM with a debug build of Nightly 40.

Comment 20

[Bob Clary [:bc] (inactive)]

the original is 404 but I tested on osx 10.{6..9}, win7 and linux and confirm no abort.