94336 - crash when viewing animated GIF with subsequent frame larger than header

Status: VERIFIED FIXED

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

Description

[Barrett Lindstrom]

This is a mozilla test case from 
http://www.mozilla.org/quality/browser/front-end/testcases/imaging/img-stress-gi
f/img-stress-gif-d.html

Viewing the gif (killerlogo3.gif) will cause the browser to crash on linux and 
hpux.  I have duplicated this with Build # 2001080800 on linux and 2001080710 on 
hpux 11i (both mozilla and netscape).

Sometimes the browser will crash after the final animation of the gif, and 
sometimes it takes pushing the "BACK" button.  This does not crash on windows.

Comment 1

[Rob Jaworski]

Using the 8/06 build on MacOS, I was able to get this killerlogo file to crash
it.  All you gotta do is load the image, let if finish cycling, then click
reload from the toolbar.

Talkback ID TB33859727G

Comment 2

[Terri Preston]

I still see this crash linux build 2001111006, for some reason talkback is
failing to recieve :-(

Comment 3

[Jay Farrell]

I saw this problem on OpenVMS from the 20011205 build. I saw it while runing
the same test, except that when I clicked killerlogo3.gif the first time it
appeared to work. I didn't see what the image said, so I clicked "Back" and re-
clicked on killerlogo3.gif and it died the second time (after it completed).

Comment 4

[Olav Vitters]

Stacktrace from todays CVS (1-2 hours ago) using Linux

(gdb) bt
#0  0x405f7289 in memcpy () from /lib/libc.so.6
#1  0x42a869c8 in ?? ()
#2  0x421fe19a in gfxImageFrame::DrawTo (this=0x8809580, aDst=0x879e3a0, aDX=0,
aDY=0, aDWidth=2000, aDHeight=2000) at ../../dist/include/xpcom/nsCOMPtr.h:650
#3  0x421c6684 in imgContainer::DoComposite (this=0x87af890,
aFrameToUse=0xbfffed50, aDirtyRect=0xbfffed60, aPrevFrame=6, aNextFrame=7) at
../../../dist/include/xpcom/nsCOMPtr.h:650
#4  0x421c5fe1 in imgContainer::Notify (this=0x87af890, timer=0x87cdde0) at
../../../dist/include/xpcom/nsCOMPtr.h:1054
#5  0x401c54b8 in nsTimerImpl::Process (this=0x87cdde0) at nsTimerImpl.cpp:243
#6  0x401c5587 in handleMyEvent (event=0x4266f088) at nsTimerImpl.cpp:278
#7  0x401bcaa4 in PL_HandleEvent (self=0x4266f088) at plevent.c:590
#8  0x401bc8d7 in PL_ProcessPendingEvents (self=0x80fca68) at plevent.c:520
#9  0x401bebc4 in nsEventQueueImpl::ProcessPendingEvents (this=0x80fca40) at
nsEventQueue.cpp:388
#10 0x418bf146 in event_processor_callback (data=0x80fca40, source=10,
condition=GDK_INPUT_READ) at nsAppShell.cpp:184
#11 0x418bed85 in our_gdk_io_invoke (source=0x8267610, condition=G_IO_IN,
data=0x8267600) at nsAppShell.cpp:77

Comment 5

[Jay Yan]

Attachment: patch for GTK version

I killed this bug in *nix->gtk version. it works fine now if I use GTK.

The reason is memory access error.

Would you please take a look at this patch? 

Jay Yan

Comment 6

[Margaret Chan]

[e-mail]:  Can we have the patch reviewed please?

Comment 7

[Stuart Parmenter]

Giving to nivedita

Comment 8

[Stuart Parmenter]

taking back.

Comment 9

[Stuart Parmenter]

Comment on attachment 68512 [details] [diff] [review]
patch for GTK version

r=pavlov

Comment 10

[Stuart Parmenter]

tor: can you sr= this?

Comment 11

[tor]

Comment on attachment 68512 [details] [diff] [review]
patch for GTK version

sr=tor

Comment 12

[Stuart Parmenter]

hmm, the patch no longer applies.  can you please post an updated patch?

Comment 13

[Margaret Chan]

Hi [e-mail]:  Jay is off till 2/18, and I don't have a current trunk
build at the moment.  Let me see if I can find someone to provide an up-to-date
patch.  If not, we'll just have to wait till Jay comes back.

Comment 14

[Joerg Baumann]

I just filed 
http://bugzilla.mozilla.org/show_bug.cgi?id=126030

I'm not able to check if these are duplicates, but nevertheless they should be
interesting for the same people

Comment 15

[Jaime Rodriguez, Jr.]

Removing nsbeta1 nomination because this bug has been plussed.

Comment 16

[Jay Yan]

Thanks, all, I will make the new patch and then submit it.

Comment 17

[Jay Yan]

Attachment: patch based on new trunk source

I got new source from trunk and create the patch again.

Comment 18

[Nivedita (gone)]

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

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Updated patch - patch had rotted due to my DrawToImage rework

This should be good for review/approval to fix this anim crash bug.  Might also
fix bug 127455.  Note that an earlier version of this patch had r/sr approval.

Comment 20

[Margaret Chan]

[e-mail] & [e-mail]:  r=, sr= for the new patch?
Can one of you check this in as well before the patch is outdated again.

Thanks, Margaret

Comment 21

[tor]

Comment on attachment 71333 [details] [diff] [review]
Updated patch - patch had rotted due to my DrawToImage rework

sr=tor

Comment 22

[Stuart Parmenter]

Comment on attachment 71333 [details] [diff] [review]
Updated patch - patch had rotted due to my DrawToImage rework

r=pavlov

Comment 23

[Asa Dotzler [:asa]]

a=asa (on behalf of drivers) for checkin to 0.9.9

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

Stuart: this is assigned to you, but if you like I'll check it in since I redid
the patch.

Comment 25

[tor]

rjesup: if you check it in, make sure you update nsImageGTK.cpp - your patch is
missing a NULL -> nsnull change in the call to dest->ImageUpdated().

Comment 26

[Randell Jesup [:jesup] (needinfo me)]

Patch tested on the testcase, no crashes.  (With nsnull, as per tor.)  I'll
check this in when the tree opens for approved checkins.  taking bug.

Comment 27

[Randell Jesup [:jesup] (needinfo me)]

Patch checked in

Comment 28

[Terri Preston]

Verified fixed linux build 2002030109, windows XP build 2002030103 and mac OS X
build 2002022808