Closed Bug 1308603 Opened 9 years ago Closed 9 years ago

Crash in mozilla::MonitorAutoLock::MonitorAutoLock & mozilla::BaseAutoLock<T>::BaseAutoLock<T>

Categories

(Core :: Audio/Video: Playback, defect, P1)

Product:
Core
Component:
Audio/Video: Playback
Version:
52 Branch
Platform:
All
Windows
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1308078
Tracking Flags:
Tracking Status
firefox52 - ---

People

(Reporter: jchen, Assigned: jwwang)

References

Details

(6 keywords)

Crash Data

Attachments

(1 file)

Bug 1308603 - add some assertions to debug crash.
58 bytes, text/x-review-board-request
kaku
: review+
Details
This bug was filed from the Socorro interface and is report bp-8a066423-b206-40ae-b41b-181d52161007. ============================================================= Crash that first appeared in the 10-06 Nightly, and it's the #1 crash for that Nightly by far. The crash stack [1] indicates something going on with MozPromise usage in media code. JW, do you think it's a regression from one of your recently landed bugs? [1] mozilla::MozPromise<mozilla::MediaDecoder::SeekResolveValue, bool, 1>::ChainTo(already_AddRefed<mozilla::MozPromise<mozilla::MediaDecoder::SeekResolveValue, bool, 1>::Private>, char const*)
Flags: needinfo?(jwwang)
[Tracking Requested - why for this release]: Regression Scrolling facebook with movies produces crashes with this signature [@ mozilla::MonitorAutoLock::MonitorAutoLock ]: https://crash-stats.mozilla.com/report/index/fcb10eb3-c34b-490e-8bd3-eb08b2161008 https://crash-stats.mozilla.com/report/index/c9249a1a-318b-4638-b293-ab0102161008 Similar issue I reported here - bug #1308609, but with different signature [@ mozilla::BaseAutoLock<T>::BaseAutoLock<T> ]
status-firefox52: --- → affected
tracking-firefox52: --- → ?
Keywords: crashreportid, regression
OS: Windows 10 → Windows
Hardware: Unspecified → All
See Also: → 1308609
Version: unspecified → 52 Branch
It looks like HandleSeek() return nullptr. http://searchfox.org/mozilla-central/rev/3e03a4064eb585d96f28023785a5c242969878a6/dom/media/MediaDecoderStateMachine.cpp#227 I will add some assertions for debugging.
Flags: needinfo?(jwwang)
Attachment #8799598 - Flags: review?(kaku)
Comment on attachment 8799598 [details] Bug 1308603 - add some assertions to debug crash. https://reviewboard.mozilla.org/r/84730/#review83316
Attachment #8799598 - Flags: review?(kaku) → review+
See Also: → 1308554
Thanks!
Assignee: nobody → jwwang
Priority: -- → P1
Every time I've seen this crash signature previously it was a UAF
Crash Signature: [@ mozilla::MonitorAutoLock::MonitorAutoLock] → [@ mozilla::MonitorAutoLock::MonitorAutoLock] [@ mozilla::BaseAutoLock<T>::BaseAutoLock<T> ]
Summary: Crash in mozilla::MonitorAutoLock::MonitorAutoLock → Crash in mozilla::MonitorAutoLock::MonitorAutoLock & mozilla::BaseAutoLock<T>::BaseAutoLock<T>
I experience this on pressing a 'Replay' button on a long youtube video.
Tracking 52+ since this is a high volume nightly crash.
tracking-firefox52: ? → +
(In reply to Anton Kochkov from comment #8) > I experience this on pressing a 'Replay' button on a long youtube video. Same here. The video I crashed on was https://www.youtube.com/watch?v=V9bZ4CLRKuc . The replay button appears in place of the play button once the video has played completely to the end.
It looks like these signatures are more than 50% of all Nightly crashes.
Crash Signature: [@ mozilla::MonitorAutoLock::MonitorAutoLock] [@ mozilla::BaseAutoLock<T>::BaseAutoLock<T> ] → [@ mozilla::MonitorAutoLock::MonitorAutoLock] [@ mozilla::BaseAutoLock<T>::BaseAutoLock<T> ] [@ RtlDispatchException | KiUserExceptionDispatcher]
Pushed by jwwang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/86499a089946 add some assertions to debug crash. r=kaku
(In reply to Markus Stange [:mstange] from comment #10) > (In reply to Anton Kochkov from comment #8) > > I experience this on pressing a 'Replay' button on a long youtube video. > > Same here. The video I crashed on was > https://www.youtube.com/watch?v=V9bZ4CLRKuc . The replay button appears in > place of the play button once the video has played completely to the end. There are a number of comments that mention the replay button. Can anyone reliably reproduce the crash?
(In reply to Marcia Knous [:marcia - use ni] from comment #15) > There are a number of comments that mention the replay button. Can anyone > reliably reproduce the crash? 1. open https://www.youtube.com/watch?v=V9bZ4CLRKuc 2. play to the end 3. press 'cancel' to stop playing next video 4. wait for 20s 5. press 'replay' 6. boom!
Depends on: 1310205
Now that we have the debugging code in, are we able to see what might be going on? Still a fairly high volume crash in Nightly.
Flags: needinfo?(jwwang)
This bug is fixed by bug 1308078. Other crashes like https://crash-stats.mozilla.com/report/index/e225722e-d7d3-4bcb-99e0-8fcbb2161017 are caused by SkAAClip::findX. Can we have more specific/detailed crash signatures so they won't attribute to wrong bugs?
Flags: needinfo?(jwwang) → needinfo?(mozillamarcia.knous)
Depends on: 1308078
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #18) > This bug is fixed by bug 1308078. > > Other crashes like > https://crash-stats.mozilla.com/report/index/e225722e-d7d3-4bcb-99e0- > 8fcbb2161017 are caused by SkAAClip::findX. Can we have more > specific/detailed crash signatures so they won't attribute to wrong bugs? To have more specific signatures, we would need to add KiUserExceptionDispatcher to the Socorro skiplist. We currently have Rtl.*, _Rtl.*, __Rtl.*, this is why we're skipping RtlDispatchException. The question is, should we always skip KiUserExceptionDispatcher to generate the signatures? If the answer is yes, then we can add it to the skiplist.
Flags: needinfo?(mozillamarcia.knous)
See Also: → 1310694
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Tracking 52- since this was duped.
tracking-firefox52: + → -
We should probably file a bug for the remaining crashes with this signature. They seem related to media playing.
(In reply to Marco Castelluccio [:marco] from comment #25) > We should probably file a bug for the remaining crashes with this signature. > They seem related to media playing. The remaining crashes has mozilla::dom::DOMIntersectionObserver::UnlinkTarget in the stack so I think they are bug 1317415
(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #26) > (In reply to Marco Castelluccio [:marco] from comment #25) > > We should probably file a bug for the remaining crashes with this signature. > > They seem related to media playing. > > The remaining crashes has > mozilla::dom::DOMIntersectionObserver::UnlinkTarget in the stack so I think > they are bug 1317415 https://crash-stats.mozilla.com/search/?signature=%3Dmozilla%3A%3AMonitorAutoLock%3A%3AMonitorAutoLock&signature=%3Dmozilla%3A%3ABaseAutoLock%3CT%3E%3A%3ABaseAutoLock%3CT%3E&signature=%3DRtlDispatchException%20%7C%20KiUserExceptionDispatcher&product=Firefox&date=%3E%3D2016-11-09T09%3A55%3A00.000Z&date=%3C2016-11-16T09%3A55%3A00.000Z&_sort=-date&_facets=signature&_facets=proto_signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-proto_signature Only the crashes with signature 'RtlDispatchException | KiUserExceptionDispatcher' have mozilla::dom::DOMIntersectionObserver::UnlinkTarget in the stack trace (not all of them though). The most recurring stacks have signature 'mozilla::MonitorAutoLock::MonitorAutoLock' and 'mozilla::BaseAutoLock<T>::BaseAutoLock<T>' and are quite different from each other. Many have 'nsSSLIOLayerHelpers::adjustForTLSIntolerance' in the stack trace.
See Also: → 1402584
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: