Closed Bug 1465775 Opened Last year Closed Last year

Crash in mozilla::Maybe<T>::operator*

Categories

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

62 Branch
Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
mozilla62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected
firefox62 --- fixed

People

(Reporter: kats, Assigned: aosmond)

References

Details

(Keywords: crash, regression, Whiteboard: [gfx-noted])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is
report bp-8cdf6dc0-2c48-4bed-90d2-9d1f80180531.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so mozilla::Maybe<nsresult>::operator* mfbt/Maybe.h:581
1 libxul.so mozilla::image::SourceBuffer::AppendFromInputStream image/SourceBuffer.cpp:525
2 libxul.so mozilla::image::RasterImage::OnImageDataAvailable image/RasterImage.cpp:989
3 libxul.so imgRequest::OnDataAvailable image/imgRequest.cpp:1205
4 libxul.so mozilla::net::nsStreamListenerTee::OnDataAvailable netwerk/base/nsStreamListenerTee.cpp:92
5 libxul.so mozilla::net::nsHttpChannel::OnDataAvailable netwerk/protocol/http/nsHttpChannel.cpp:7543
6 libxul.so nsInputStreamPump::OnStateTransfer netwerk/base/nsInputStreamPump.cpp:593
7 libxul.so nsInputStreamPump::OnInputStreamReady netwerk/base/nsInputStreamPump.cpp:428
8 libxul.so nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:102
9 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1088

=============================================================


Seen in crash-stats. This crash appears a couple of times in the last 7 days, both on FennecAndroid.
I've touched this area recently. Probably my fault.
Component: Graphics → ImageLib
Priority: -- → P3
Whiteboard: [gfx-noted]
SourceBuffer::Append has no path in which it fails, and SourceBuffer::mStatus is Nothing. As such, I can only conclude that aInputStream in SourceBuffer::AppendFromInputStream itself failed to read the requested number of bytes, despite the fact we were told how many are available. We used to just ignore this. Reviewing a few other OnDataAvailable listeners (e.g. EventSourceImpl::OnDataAvailable, nsPingListener::OnDataAvailable, FetchDriver::OnDataAvailable, CSPViolationReportListener::OnDataAvailable), it seems they aren't too upset if there is a size mismatch. I'll make it fail only if there was an allocation failure inside SourceBuffer, but not assume there is.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Depends on: 1453454
Keywords: regression
Duplicate of this bug: 1466619
(the signature from the duped bug)
Crash Signature: [@ mozilla::Maybe<T>::operator*] → [@ mozilla::Maybe<T>::operator*] [@ mozilla::image::SourceBuffer::AppendFromInputStream ]
Attachment #8982302 - Flags: review?(tnikkel) → review+
Pushed by aosmond@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/47f3020c6aa7
Fix crash in SourceBuffer::AppendFromInputStream due to incomplete read. r=tnikkel
https://hg.mozilla.org/mozilla-central/rev/47f3020c6aa7
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in before you can comment on or make changes to this bug.