Closed Bug 94336 Opened 23 years ago Closed 23 years ago

crash when viewing animated GIF with subsequent frame larger than header

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: BarrettLndstrm, Assigned: jesup)

References

()

Details

(Keywords: crash)

Attachments

(1 file, 2 obsolete files)

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.
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
I still see this crash linux build 2001111006, for some reason talkback is failing to recieve :-(
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).
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
Keywords: crash
OS: Linux → All
Hardware: PC → All
Blocks: 119597
Keywords: nsbeta1
Target Milestone: --- → Future
Attached patch patch for GTK version (obsolete) (deleted) — Splinter Review
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
pavlov@netscape.com: Can we have the patch reviewed please?
Giving to nivedita
Assignee: pavlov → nivedita
Target Milestone: Future → ---
taking back.
Assignee: nivedita → pavlov
Target Milestone: --- → mozilla0.9.9
Comment on attachment 68512 [details] [diff] [review] patch for GTK version r=pavlov
Attachment #68512 - Attachment is patch: true
Attachment #68512 - Flags: review+
tor: can you sr= this?
Comment on attachment 68512 [details] [diff] [review] patch for GTK version sr=tor
Attachment #68512 - Flags: superreview+
hmm, the patch no longer applies. can you please post an updated patch?
Hi pavlov@netscape.com: 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.
Keywords: nsbeta1+
Status: NEW → ASSIGNED
Keywords: patch
Priority: -- → P2
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
Removing nsbeta1 nomination because this bug has been plussed.
Keywords: nsbeta1
Thanks, all, I will make the new patch and then submit it.
Attached file patch based on new trunk source (obsolete) (deleted) —
I got new source from trunk and create the patch again.
*** Bug 125894 has been marked as a duplicate of this bug. ***
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.
Attachment #68512 - Attachment is obsolete: true
Attachment #70699 - Attachment is obsolete: true
pavlov@netscape.com & tor@acm.com: r=, sr= for the new patch? Can one of you check this in as well before the patch is outdated again. Thanks, Margaret
Comment on attachment 71333 [details] [diff] [review] Updated patch - patch had rotted due to my DrawToImage rework sr=tor
Attachment #71333 - Flags: superreview+
Comment on attachment 71333 [details] [diff] [review] Updated patch - patch had rotted due to my DrawToImage rework r=pavlov
Attachment #71333 - Flags: review+
a=asa (on behalf of drivers) for checkin to 0.9.9
Keywords: mozilla0.9.9+
Stuart: this is assigned to you, but if you like I'll check it in since I redid the patch.
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().
Keywords: mozilla0.9.9+
Keywords: mozilla0.9.9+
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.
Assignee: pavlov → rjesup
Status: ASSIGNED → NEW
Patch checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified fixed linux build 2002030109, windows XP build 2002030103 and mac OS X build 2002022808
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: