Crash in [@ mozilla::GetShutdownBarrier]
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox-esr78 | --- | unaffected |
| firefox79 | --- | unaffected |
| firefox80 | --- | wontfix |
| firefox81 | --- | wontfix |
| firefox82 | --- | fixed |
People
(Reporter: philipp, Assigned: bryce)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
This bug is for crash report bp-89f65ff7-77a1-45d6-83b3-8d2c20200818.
Top 10 frames of crashing thread:
0 xul.dll mozilla::GetShutdownBarrier dom/media/MediaShutdownManager.cpp:51
1 xul.dll static mozilla::MediaShutdownManager::InitStatics dom/media/MediaShutdownManager.cpp:74
2 xul.dll mozilla::dom::HTMLMediaElement::Init dom/html/HTMLMediaElement.cpp:4227
3 xul.dll NS_NewHTMLVideoElement dom/html/HTMLVideoElement.cpp:47
4 xul.dll CreateHTMLElement dom/html/nsHTMLContentSink.cpp:234
5 xul.dll static nsContentUtils::NewXULOrHTMLElement dom/base/nsContentUtils.cpp:9205
6 xul.dll NS_NewElement dom/base/nsNameSpaceManager.cpp:183
7 xul.dll mozilla::dom::Document::CreateElement dom/base/Document.cpp:7712
8 xul.dll mozilla::dom::Document_Binding::createElement dom/bindings/DocumentBinding.cpp:1203
9 xul.dll mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3220
these tab crashes with moz crash reason MOZ_RELEASE_ASSERT(svc) from bug 1274522 are increasing in volume since firefox 80 (first affected nightly was 80.a1 build 20200715215205).
|
||
Comment 1•4 years ago
|
||
Under which circumstances could services::GetAsyncShutdownService() return nullptr?
Would you know what changed in FF80 to have such a spike in crashes?
|
Assignee | |
Comment 2•4 years ago
|
||
Looks like we shouldn't be asserting here. I don't know why the uptick in crashes, but if we're in shutdown we'll fail to fetch services, so this is a semi-expected outcome.
|
|
Assignee | |
Comment 3•4 years ago
|
||
Gracefully handle failure to get the shutdown service by returning null when
trying to fetch a barrier rather than asserting. We then gracefully handle the
failure to get a barrier when adding a shutdown blocker. We still assert when
removing a blocker -- my thinking in this case is that we're failing to get the
service because we're already shutdown, however, if we have a blocker added we
should never shutdown until it's removed.
Pushed by bvandyk@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/69158f3aa05b Gracefully handle failure to get AsyncShutdownService in MediaShutdownManger. r=froydnj
|
||
Comment 5•4 years ago
|
||
| bugherder | ||
|
||
Comment 6•4 years ago
|
||
Is this something we should consider uplifting to Beta?
|
|
Assignee | |
Comment 7•4 years ago
|
||
I don't think it's a big deal either way. My guesstimate is that the assert/crash is low impact and will happen when we're already in shutdown. I.e. users won't notice a crash dialog as the page is going away anyway, and since this is an assert there's not security concerns.
My inclination would be to let it ride the trains, but I don't feel strongly and am happy to request uplift if anyone would prefer.
|
||
Comment 8•4 years ago
|
||
The patch landed in nightly and beta is affected.
:bryce, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
For more information, please visit auto_nag documentation.
|
||
Comment 10•3 years ago
|
||
Crashes with this signature @ mozilla::media::GetShutdownBarrier are popping up especially on ESR. Could they be related to this or should I file another bug? Note that crash volume from ESR cannot be compared directly with release because we only process ~10% of the crashes submitted from release, but we accept 100% of the crashes submitted by ESR builds.
|
|
Assignee | |
Comment 11•3 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #10)
Crashes with this signature @ mozilla::media::GetShutdownBarrier are popping up especially on ESR. Could they be related to this or should I file another bug? Note that crash volume from ESR cannot be compared directly with release because we only process ~10% of the crashes submitted from release, but we accept 100% of the crashes submitted by ESR builds.
Could you file a new bug and NI me, please? Looks like code changes removed some of the safety checking this bug did. Probably best to fix in a another bug. I believe bug 1674845 regressed this.
Description
•