Closed Bug 932820 Opened 8 years ago Closed 7 years ago
crash in mozilla::Media
Plugin Reader::Decode Video Frame(bool&, long long) HTC One/Adreno 320
This bug was filed from the Socorro interface and is report bp-cd5ff84d-754b-4e0f-9927-45d8b2131030. ============================================================= 0 libxul.so mozilla::MediaPluginReader::DecodeVideoFrame(bool&, long long) obj-firefox/dist/include/AbstractMediaDecoder.h 1 libxul.so mozilla::MediaDecoderReader::DecodeToTarget(long long) content/media/MediaDecoderReader.cpp 2 libxul.so mozilla::MediaPluginReader::Seek(long long, long long, long long, long long) content/media/plugins/MediaPluginReader.cpp 3 libxul.so mozilla::MediaDecoderStateMachine::DecodeSeek() content/media/MediaDecoderStateMachine.cpp 4 libxul.so mozilla::MediaDecoderStateMachine::DecodeThreadRun() content/media/MediaDecoderStateMachine.cpp 5 libxul.so nsRunnableMethodImpl<tag_nsresult (mozilla::dom::NotificationPermissionRequest::*)(), true>::Run() obj-firefox/dist/include/nsThreadUtils.h 6 libxul.so nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 7 libxul.so NS_ProcessNextEvent(nsIThread*, bool) obj-firefox/xpcom/build/nsThreadUtils.cpp 8 libxul.so nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp 9 libnss3.so _pt_root nsprpub/pr/src/pthreads/ptthread.c 10 libc.so libc.so@0xcbe2 11 libc.so libc.so@0xcd5e Aaron can you repo on the HTC One, if you need URLs just ask.
Nightly, blocked on video playback on my HTC One, I am hitting bug crasher 933325. On release, I haven't hit this yet but am still trying.
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2) > Maire, assignee? This is in media playback. Anthony, I know everyone is super busy right now, but can you find someone to look at this?
Flags: needinfo?(mreavy) → needinfo?(ajones)
8 years ago
Assignee: nobody → edwin
This is a top 10 crash for Firefox for Android 26. Any chance this could be looked into?
Has this been observed recently on FF27+? I was seeing a similar crash which I fixed in bug 934412. Might just have to uplift those to release.
Flags: needinfo?(edwin) → needinfo?(kbrosnan)
Crash stats has crashes on 29a1, 28a2, 27b1 and 26, 25, 24 release. I don't think 934412 is related given that 26 is unaffected for that bug.
I can't really dogfood nightly on my HTC One - after the break, can we please bump this up in priority?
Any news on this?
If this is still a top-crash this should be tracking 27. Kevin, re-nominate if so.
Can still repro on latest nightly. On it soon.
Yes this is a topcrash. It is on release. Not much to do till there is a patch. Once that appears it can be evaluated for uplift.
7 years ago
Duplicate of this bug: 953234
The issue here is that HTC extends OMXCodec with their own HTCOMXCodec, whose read() method modifies the ReadOptions object passed into it. That in itself wouldn't be too bad, but they have also extended ReadOptions with extra fields. So when we pass ReadOptions (allocated on the stack) by address into [HTC]OMXCodec::read(), it writes over our stack since ReadOptions isn't as long as it expects.
Attachment #8362755 - Flags: review?(chris.double)
How safe is this patch to uplift? This is currently #6 crash on Fx26. I don't think we can uplift to release, but beta would be nice. We might have just missed that too.
(In reply to Mark Finkle (:mfinkle) from comment #14) > How safe is this patch to uplift? This is currently #6 crash on Fx26. I > don't think we can uplift to release, but beta would be nice. We might have > just missed that too. Bustage risk is zero. Go ahead.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
(In reply to Mark Finkle (:mfinkle) from comment #14) > How safe is this patch to uplift? This is currently #6 crash on Fx26. I > don't think we can uplift to release, but beta would be nice. We might have > just missed that too. We have our final beta for mobile going to build on Monday(1/27). Would recommend to nominate for uplift with risk evaluation. If low risk, I am in favor of landing if we can mitigate the risk by some extra testing or bake time on aurora ? Nevertheless, lets uplift to aurora asap.
Comment on attachment 8362755 [details] [diff] [review] 932820.patch [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Top crash Testing completed (on m-c, etc.): Just landed on m-c Risk to taking this patch (and alternatives if risky): "Bustage risk is zero" String or IDL/UUID changes made by this patch: none
Attachment #8362755 - Flags: approval-mozilla-aurora?
Attachment #8362755 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8362755 [details] [diff] [review] 932820.patch [Approval Request Comment] Same as for Aurora. This is the #6 crash on Fx26, so getting this fixed in Fx27 would be great.
Attachment #8362755 - Flags: approval-mozilla-beta?
Attachment #8362755 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
For verification, it should be noted that this crash happened on *seeking* an h264 video.
WFM on my HTC One (Android 4.3, Sense 5.5), tested against Nightly.
You need to log in before you can comment on or make changes to this bug.