Closed Bug 1106448 Opened 9 years ago Closed 9 years ago

crash in mozilla::image::imgFrame::LockImageData()

Categories

(Core :: Graphics: ImageLib, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla37
Tracking Status
firefox36 --- verified
firefox37 --- verified
b2g-v2.2 --- fixed

People

(Reporter: MatsPalmgren_bugz, Assigned: seth)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-61fb49f5-b5e3-4315-8dbf-b41bd2141128.
=============================================================

This appears to be a new crash, first occurring in Nightly 20141128080044.
Maybe a regression from bug 1060869?

mozilla::image::imgFrame::LockImageData()
mozilla::image::Decoder::GetCurrentFrameRef()
mozilla::image::nsICODecoder::AllocateFrame()
mozilla::image::RasterImage::InitDecoder(bool)
mozilla::image::RasterImage::RequestDecodeCore(mozilla::image::RasterImage::RequestDecodeType)
mozilla::image::RasterImage::RequestDecodeIfNeeded(tag_nsresult, mozilla::image::ShutdownReason, bool, bool)
mozilla::image::RasterImage::FinishedSomeDecoding(mozilla::image::ShutdownReason, unsigned int)
mozilla::image::DecodePool::DecodeUntilSizeAvailable(mozilla::image::RasterImage*)
mozilla::image::RasterImage::DoImageDataComplete()
mozilla::image::RasterImage::OnImageDataComplete(nsIRequest*, nsISupports*, tag_nsresult, bool)
imgRequest::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult)
ProxyListener::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult)
nsBaseChannel::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult)
nsInputStreamPump::OnStateStop()
nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*)
nsInputStreamReadyEvent::Run()
nsThread::ProcessNextEvent(bool, bool*)
Flags: needinfo?(seth)
Looks like in nsICODecoder::AllocateFrame we always call GetCurrentFrameRef, but it may crash if AllocateFrame fails. We could check the return value of AllocateFrame before calling it, but since GetCurrentFrame() is safe even if there is no current frame (it just returns null), I think we'd be better off making GetCurrentFrameRef() consistent with that and just return an empty RawAccessFrameRef if we have no mCurrentFrame. I imagine when writing this code originally I assumed that it did work that way.
Attachment #8531616 - Flags: review?(tnikkel)
Assignee: nobody → seth
Status: NEW → ASSIGNED
Flags: needinfo?(seth)
Attachment #8531616 - Flags: review?(tnikkel) → review+
Thanks for the review! Pushed:

https://hg.mozilla.org/integration/mozilla-inbound/rev/5f0fc1b9b966

This should get uplifted to Aurora if there are no problems on central.
https://hg.mozilla.org/mozilla-central/rev/5f0fc1b9b966
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Comment on attachment 8531616 [details] [diff] [review]
Make sure we have a frame in GetCurrentFrameRef

Approval Request Comment
[Feature/regressing bug #]: 1057904
[User impact if declined]: Crashes.
[Describe test coverage new/current, TBPL]: On central.
[Risks and why]: Very low risk.
[String/UUID change made/needed]: None.
Attachment #8531616 - Flags: approval-mozilla-aurora?
Attachment #8531616 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.