Closed Bug 411874 Opened 18 years ago Closed 18 years ago

Crash [@ ffff068b nsGIFDecoder2::EndImageFrame] while loading MySpace page (hard to repro)

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: stephend, Assigned: alfredkayser)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

Summary: Crash [@ ffff068b nsGIFDecoder2::EndImageFrame] while loading MySpace page (hard to repro) Vague Steps to Reproduce: 1. Load http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=32991097 while Pandora.com is also loading 2. Crash, sometimes (once?) here: 0 @0xffff068b 1 nsGIFDecoder2::EndImageFrame() mozilla/modules/libpr0n/decoders/gif/nsGIFDecoder2.cpp:399 2 nsGIFDecoder2::Close() mozilla/modules/libpr0n/decoders/gif/nsGIFDecoder2.cpp:165 3 imgRequest::OnStopRequest(nsIRequest*, nsISupports*, unsigned int) mozilla/modules/libpr0n/src/imgRequest.cpp:723 4 nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, unsigned int) mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:4412 5 nsInputStreamPump::OnStateStop() mozilla/netwerk/base/src/nsInputStreamPump.cpp:576 6 nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) mozilla/netwerk/base/src/nsInputStreamPump.cpp:401 7 nsInputStreamReadyEvent::Run() mozilla/gfx/cairo/cairo/src/cairo-hull.c:107 8 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:510 9 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) nsThreadUtils.cpp:180 10 nsBaseAppShell::NativeEventCallback() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:112 11 nsAppShell::ProcessGeckoEvents(void*) mozilla/widget/src/cocoa/nsAppShell.mm:294
The problem seems to be here: 394 reed 1.91 // Only add frame if we have any rows at all 395 if (mGIFStruct.rows_remaining != mGIFStruct.height) { 396 if (mGIFStruct.rows_remaining && mGIFStruct.images_decoded) { 397 // Clear the remaining rows (only needed for the animation frames) 398 PRUint8 *rowp = mImageData + ((mGIFStruct.rows_remaining - mGIFStruct.height) * mGIFStruct.width); 399 memset(rowp, 0, mGIFStruct.rows_remaining * mGIFStruct.width); 400 } In the calculation for the offset into the part that needs to be cleared, I did: mGIFStruct.rows_remaining - mGIFStruct.height But actually rows_remaining is number of rows not filled by the frame (e.g. 2 rows not filled), and height is total number rows is 15. This means mGIFStruct.rows_remaining - mGIFStruct.height results in a negative number (-13) which is clearly the wrong offset... Patch coming up... (I don't have cvs access during the day)
But it would help greatly if one could determine which .gif file is causing this problem. Both sites have a number of GIF's, and they are also different depending current advertising and/or location (For example, I got Dutch advertising...)
(In reply to comment #2) > But it would help greatly if one could determine which .gif file is causing > this problem. Both sites have a number of GIF's, and they are also different > depending current advertising and/or location (For example, I got Dutch > advertising...) Alfred, I believe a somewhat-more-reliable testcase than I've given is the following: 1. Load http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=132672179 (different profile, crasher for me more often) 2. Click on the profile picture (http://viewmorepics.myspace.com/index.cfm?fuseaction=user.viewAlbums&friendID=132672179) before the background (http://img.photobucket.com/albums/v221/ashbernie311/welife/welife3/vintageglam_floral.gif), i.e., when the page has a white background. Keep playing with that, and hopefully you'll crash :-)
Sadly you need an account on myspace to find a reliable testcase. I don't have one so I cannot help ATM. :/
With patch I cannot reproduce this crash anymore. (the current FF3 build does seem to crash to the testcase above).
Assignee: nobody → alfredkayser
Status: NEW → ASSIGNED
Attachment #297710 - Flags: review?(pavlov)
Blocks: 409878
OS: Mac OS X → All
Attachment #297710 - Flags: review?(pavlov) → review+
Attachment #297710 - Flags: approval1.9?
Can we get this image into our testsuite Dolske?
Attachment #297710 - Flags: approval1.9? → approval1.9+
Flags: in-testsuite?
Keywords: checkin-needed
Was anyone able to narrow this down to a specific image? Maybe enable network logging to figure out what image url was loading right before the crash?
Checking in modules/libpr0n/decoders/gif/nsGIFDecoder2.cpp; /cvsroot/mozilla/modules/libpr0n/decoders/gif/nsGIFDecoder2.cpp,v <-- nsGIFDecoder2.cpp new revision: 1.92; previous revision: 1.91 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
Just an update: dolske and I spent at least an hour each trying to isolate the crashing GIF, and weren't able to.
Suspicion in bug 412294 is that it was a duplicate of this bug. If so, I have isolated the responsible GIF there.
Attached image GIF from bug 412294
This is the GIF causing bug 412294 (duped to this bug). It's a looping animated GIF, so it can probably only be used as a "doesn't crash when loaded" test.
Attachment #299519 - Attachment is patch: false
Attachment #299519 - Attachment mime type: text/plain → image/gif
Hmm. I checked with a nightly (OS X, Gecko/2008011304) from before the patch landed, and that GIF doesn't cause a crash for me. Seems to load and display the same as in FF2.
I can reproduce a crash with the given steps in bug 412294 comment 3 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008011504 Minefield/3.0b3pre ID:2008011504 and it doesn't occur anymore in current nightly builds. The stack looks like following: bp-3cb9a9d4-ccd6-11dc-a87f-001a4bd43ed6 But it doesn't look like that it has anything to do with this bug. I have isolated the gif which is another one as the latest attachment on this bug. Hitting shift-reload as fast as possible lets an nightly build crash.
Attachment #299548 - Attachment is patch: false
Attachment #299548 - Attachment mime type: text/plain → image/gif
Perhaps you have to save the image locally before you notice the crash! I'm not able to crash the browser while viewing the attachment?
Alfred, this kind of crash still happens on Windows. You duped bug 412294 which is about RtlpCoalesceFreeBlocks against this bug. Reopening? http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b3pre&range_value=2&signature=RtlpCoalesceFreeBlocks
If you look at: http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b3pre&range_value=2&signature=RtlpCoalesceFreeBlocks and sort on 'build', you can see that the latest build from which these crash reports came, you can see: 2008020104 That is precisely the date when this patch was committed to the trunk. So, the are no crash reports after that, so I still consider this bug and its dup(s) has fixed.
Do you mean with "this patch" the patch on this bug? As I can see in comment 8 it was committed to trunk on 2008-01-18 and not 2008-02-01.
No crashes anymore since 2008-02-05. Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021004 Minefield/3.0b4pre ID:2008021004
Status: RESOLVED → VERIFIED
Hardware: PC → All
Crash Signature: [@ ffff068b nsGIFDecoder2::EndImageFrame]
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: