22519 - Crash on a malformed animated GIF

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Andreas Jung]

Env: WinNT 4.0 SP6

Comment 1

[Sean Richardson]

Crash confirmed with 2000-01-01-08-M13 nightly binary on Windows NT 4.0sp3;
IE5 diplays the page fine.

The page loads until all of the content is visible except the complete sequence
of frames for the animated gif on the left. About 4 or 5 frames display before
the crash.

Saved this gif "IMAG0001.gif" to local disk from IE; Mozilla displayed the
first 4 or 5 frames and then sat there, with the throbber and candystripe
continuing to cycle "forever" - [Back] still worked, though.
NN4.7 froze entirely (all windows) after displaying about the 4th or 5th
frame of the gif.

Based on that, the gif may have some invalid data in it control channel,
or may be using some part of the gif89a spec that is not commonly implemented.

Needless to say, Mozilla shouldn't crash even if it is asked to handle severely
damaged images.

Setting Component to "ImageLib" from "Browser-General".

I'm not going to say any more about this crash, either.

Comment 2

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 3

[neeti]

Moving to m17

Comment 4

[neeti]

Changing priority to P2.

Comment 5

[David Hallowell]

Attachment: GIF image that crashes Mozilla and Netscape

Comment 6

[David Hallowell]

I don't know if it's related to this crash but on a web page called The Bomb
http://web.mouser.org/bomb/index2.html there's a GIF image that's been designed
to crash web browsers[1]. I've attached this image for reference.

I've got the following talkback IDs related to these crashes:
Using Mozilla M14 (build ID 2000030316  Linux Slackware 7):
TB8520307K (for the deadly image I've attached)
TB8521257Z  (using the URL for the original bug report - see URL field)

Using Netscape 6 (build ID 2000032406 Linux Slackware 7):
TB8520965Y (for the deadly image I've attached)
TB8520755K (for the pacge referenced in this bugs URL field)

[1] Original URL for deadly GIF image: http://web.mouser.org/bomb/youdead.gif

Please note the affects all operating systems supported by Mozilla but I'm
unable to change the OS settings because I don't have sufficient priviledge :(

Comment 7

[Eli Goldberg]

David, another bug exists for that; I don't know the number, but you can find it 
by querying for bugs reported by terry.

Comment 8

[David Hallowell]

Ahh yes, I've found it (bug #22754 if anyone's interested)

Comment 9

[Stephen Ostermiller]

Can somebody change the summary so that it has "gif" in it?  You should be able
to find this bug by searching for gif with a keyword of crash.

Another page that crashes mozilla with animated gifs:
http://www.tc.cornell.edu/Visualization/contrib/cs418-sp94/1998/KilledKenny/cablewheel.html

Comment 10

[Antti Näyhä]

Changed the URL to the specific image that crashes Mozilla, and updated summary 
accordingly.

BTW, I'm able to reproduce this on build 2000-07-21-08 (WinNT4 SP6a).

Comment 11

[Sean Richardson]

Some additional data, based on testing with 2000-07-31-08-M18 on WinNT: 

A) 1. The crash is not 100 percent reproducible viewing
      http://du.altawixa.de/rubbergay/Seite_3/IMAG0001.GIF - when it does not
      happen, the browser appears to operate normally thereafter.
   2. In (1) whether the crash happens or not, after a few frames the image load
      fails and the URL replaces it on the canvas (before the crash).
   3. Viewing the same image saved (from IE) to a file, the crash alays happens.
   4. Viewing the page http://du.altawixa.de/rubbergay/Seite_3x.html, the crash 
      always happens after the first few frames of IMAG0001.GIF are displayed.
   5. In neither (3) nor (4) does the URL appear before the crash.
   6. If the image load failure describe in (2) did not result in a crash,
      showing the URL instead of the animated image on the page may suffice for 
      first shipping, for this image... see (B)...  

B) Loading the saved IMAG0001.GIF into programmes that grok gif89a animation,
   results vary:
     * Corel Photopaint 7 see eight (8) frames, in an abcddcba pattern.
     * Corel Photopaint 9 sees twenty-seven (27) frames.
     * Alchemy Mindworks' Gif Construction Set sees twenty-seven (27) 
       unique frames (no reuse of earlier frames); previewing the animation,
       only flashes of the frames appear, stroboscopically, and the entire
       animation appears to be going up-(repeat)-up-(repeat)...,
       not up-down-(repeat)-up-down-(repeat).
     * Looking at the control channel info, the delay before each frame is 0. 
       There appear to be 8 palettes between the start and midpoint of the
       animation, each ordered from darkest to lightest colour. Each has a few 
       more colours than the last, and a different index for the transparent
       colour. The same palettes are reused in the inverse order in the second 
       half of the animation.
     
C) Talkback incident ID: TB15123632E (for viewing page).

Comment 12

[Paul Wyskoczka]

Updating QA Contact

Comment 13

[pnunn]

this bug is still with us.

NTDLL! 77f7d622()
NTDLL! 77f64dd5()
_free_base(void * 0x04554c70) line 60
_free_dbg_lk(void * 0x04554c90, int 0x00000001) line 1083 + 9 bytes
_free_dbg(void * 0x04554c90, int 0x00000001) line 970 + 13 bytes
free(void * 0x04554c90) line 926 + 11 bytes
PR_Free(void * 0x04554c90) line 66 + 10 bytes
ImageConsumer::~ImageConsumer() line 569 + 13 bytes
ImageConsumer::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
ImageConsumer::Release(ImageConsumer * const 0x04ba6570) line 172 + 132 bytes
ImageListener::~ImageListener() line 112 + 27 bytes
ImageListener::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
ImageListener::Release(ImageListener * const 0x04b7eec0) line 115 + 129 bytes
nsCOMPtr<nsIStreamListener>::assign_assuming_AddRef(nsIStreamListener * 
0x00000000) line 472
nsCOMPtr<nsIStreamListener>::assign_with_AddRef(nsISupports * 0x00000000) line 
849
nsCOMPtr<nsIStreamListener>::operator=(nsIStreamListener * 0x00000000) line 584
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x03f93250, 
nsIChannel * 0x03f92e90, nsISupports * 0x00000000, unsigned int 0x80004004, 
const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 279
nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x03f931f0, 
nsIChannel * 0x03f92e90, nsISupports * 0x00000000, unsigned int 0x80004004, 
const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1159 + 42 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 
0x04b7c4d0, nsIChannel * 0x03f92e90, nsISupports * 0x00000000, unsigned int 
0x80004004, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1207
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x04b7c4d0, unsigned int 
0x80004004, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1923 + 42 
bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x04b79040, 
nsIChannel * 0x04371d14, nsISupports * 0x03f92e90, unsigned int 0x80004004, 
const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 730
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x04b79a60) line 
302
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x04b79960) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x04b79960) line 580 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a7d510) line 513 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00f90488, unsigned int 0x0000c0dc, unsigned int 
0x00000000, long 0x00a7d510) line 1049 + 9 bytes
USER32! 77e71820()
00a7d510()

Comment 14

[pnunn]

subsequent frames are larger than the screen frame.
The allocations for the subsequent frames isn't working properly.
Gack. I hate this image.

Comment 15

[pnunn]

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

Comment 16

[Stuart Parmenter]

reassigning to mr gif

Comment 17

[saari (gone)]

we don't crash anymore with this. Not quite displaying right because I havn't
fixed all the frame replacement options in GIF anims yet, but that is a
different bug. Fixed.

Comment 18

[Terri Preston]

Verified fix in w2k 2001040304
Verified fix in linux 2001040305
Verified fix in mac 2001040213