1911632 - Crash in [@ mozilla::media::MustGetShutdownBarrier]

Status: NEW

(Core :: WebRTC: Audio/Video, defect)

Description

[Chris Peterson [:cpeterson]]

Crash report: https://crash-stats.mozilla.org/report/index/c51be92e-b570-434c-b7c9-64f4f0240803

About 70% of these crash reports are from Android, but we also have reports from Windows and macOS.

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(barrier)

Top 10 frames:

0  libxul.so  mozilla::media::MustGetShutdownBarrier()  dom/media/systemservices/MediaUtils.cpp:35
1  libxul.so  mozilla::MediaManager::Get()  dom/media/MediaManager.cpp:2476
2  libxul.so  mozilla::dom::MediaDevices::MaybeResumeDeviceExposure()  dom/media/MediaDevices.cpp:203
3  libxul.so  mozilla::dom::MediaDevices::WindowResumed()  dom/media/MediaDevices.h:99
3  libxul.so  nsGlobalWindowInner::Resume(bool)  dom/base/nsGlobalWindowInner.cpp:5645
4  libxul.so  mozilla::dom::BrowsingContextGroup::UpdateToplevelsSuspendedIfNeeded()  docshell/base/BrowsingContextGroup.cpp:280
5  libxul.so  mozilla::dom::BrowsingContext::DidSet(std::__ndk1::integral_constant<unsigned...  docshell/base/BrowsingContext.cpp:2658
5  libxul.so  mozilla::dom::syncedcontext::Transaction<mozilla::dom::BrowsingContext>::Appl...  docshell/base/SyncedContextInlines.h:224
5  libxul.so  mozilla::dom::syncedcontext::FieldValues<mozilla::dom::BrowsingContext::BaseF...  docshell/base/SyncedContext.h:168
5  libxul.so  mozilla::dom::syncedcontext::FieldValues<mozilla::dom::BrowsingContext::BaseF...  docshell/base/SyncedContext.h:154

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Andreas Pehrson [:pehrsons]]

Normally I'd expect GetShutdownBarrier to fail only if we're in shutdown. But main thread stacks clearly say we are not (I'd have expected ContentProcess::CleanUp on the stack).

Also, we crash on a release assert due to GetShutdownBarrier() failing, which is after passing a release assert for getting a barrier out of nsIAsyncShutdownService.

This means services::GetAsyncShutdownService() returned nullptr.

Either something must have stomped on gXPCOMShuttingDown (seems unlikely), or do_GetService("@mozilla.org/async-shutdown-service;1") failed. The paper trail for the latter goes via either CallGetService failing, gComponentManager being null, or an issue deeper in nsComponentManager (a non-trivial amount of failure modes so seems more likely).

Moving to XPCOM for further diagnosis.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

The async shutdown service is implemented in JS, so technically any interaction with it is always possible to fail (e.g. due to a JS OOM exception).

Bug 1760855 is for making this not be the case eventually, but there are no plans to do this right now, as it's a pretty substantial process.

Comment 5

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:nika, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Nika Layzell [:nika] (ni? for response)]

I should also note that this bug is in a content process, so the profileBeforeChange barrier (https://searchfox.org/mozilla-central/rev/f2c181a7ab3bfea4d2266521e6eac713630479b3/dom/media/systemservices/MediaUtils.cpp#21-22) is guaranteed to not be present (https://searchfox.org/mozilla-central/rev/f2c181a7ab3bfea4d2266521e6eac713630479b3/toolkit/components/asyncshutdown/AsyncShutdown.sys.mjs#1102), and xpcomWillShutdown is never reached by a content process in a non-leakchecking build.

Comment 7

[Andreas Pehrson [:pehrsons]]

We'll let this crash for now.

Me and karlt has discussed this a bit.
The best fix here would be to use an infallible shutdown blocker, so that's option 1. Marking bug 1760855 as a dependency because of this.
Option 2 would be to ignore the lack of a shutdown barrier where it doesn't matter. I.e in content processes of non-leakchecking builds. But we also noted MediaManager may be used in the parent process (e.g. gDM permission prompt previews), and the fast-shutdown phase in the parent process is after xpcom-shutdown-threads which MediaManager likely relies on.
Option 3 would be to gracefully handle the failure case of getting a shutdown barrier by e.g. making MediaManager unavailable, but this seems like opening a can of worms. The added complexity may reach far and is hard to overview.

Also note that this is not just MediaManager. See for instance media::ShutdownBlockingTicket which assumes the same barrier availability.

Should the crash-rate go up so we want to do something short-term here, option 2 seems most reasonable.

Comment 8

[Jianfeng Liu]

I have similar crash with firefox 139 packaged by debian on loong64 architecture:

Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
mozilla::dom::ServiceWorkerRegistrar::ProfileStarted (this=0x7fffdfb68220) at ./dom/serviceworkers/ServiceWorkerRegistrar.cpp:1510
warning: 1510	./dom/serviceworkers/ServiceWorkerRegistrar.cpp: No such file or directory
(gdb) bt
#0  mozilla::dom::ServiceWorkerRegistrar::ProfileStarted (this=0x7fffdfb68220) at ./dom/serviceworkers/ServiceWorkerRegistrar.cpp:1510
#1  0x00007fffe92995c0 in mozilla::dom::ServiceWorkerRegistrar::Observe (this=0x7fffdfb68220, aSubject=<optimized out>, aTopic=<optimized out>, aData=<optimized out>) at ./dom/serviceworkers/ServiceWorkerRegistrar.cpp:1672
#2  0x00007fffe5f079dc in nsObserverList::NotifyObservers (this=<optimized out>, aSubject=0x0, aTopic=0x7fffe3760727 "profile-after-change", someData=0x7fffe4a0b854 <nsXREDirProvider::DoStartup()::kStartup> u"startup") at ./xpcom/ds/nsObserverList.cpp:71
#3  nsObserverService::NotifyObservers (this=<optimized out>, aSubject=0x0, aTopic=0x7fffe3760727 "profile-after-change", aSomeData=0x7fffe4a0b854 <nsXREDirProvider::DoStartup()::kStartup> u"startup") at ./xpcom/ds/nsObserverService.cpp:288
#4  0x00007fffe9deb9a4 in nsXREDirProvider::DoStartup (this=<optimized out>) at ./toolkit/xre/nsXREDirProvider.cpp:651
#5  0x00007fffe9de0d8c in XREMain::XRE_mainRun (this=0x7ffffbf768b8) at ./toolkit/xre/nsAppRunner.cpp:5668
#6  0x00007fffe9de1838 in XREMain::XRE_main (this=0x7ffffbf768b8, argc=<optimized out>, argv=<optimized out>, aConfig=<optimized out>) at ./toolkit/xre/nsAppRunner.cpp:6136
#7  0x00007fffe9de1df4 in XRE_main (argc=45, argv=0xe87227fc0e9a2500, aConfig=...) at ./toolkit/xre/nsAppRunner.cpp:6209
#8  0x0000555558f002bc in do_main (argc=<optimized out>, argv=0x7ffffbf77c58, envp=<optimized out>) at ./browser/app/nsBrowserApp.cpp:232
#9  main (argc=1, argv=0x7ffffbf77c58, envp=<optimized out>) at ./browser/app/nsBrowserApp.cpp:464

After patching this crash ( I guess it is Option 3 above):

--- firefox-139.0.orig/dom/serviceworkers/ServiceWorkerRegistrar.cpp
+++ firefox-139.0/dom/serviceworkers/ServiceWorkerRegistrar.cpp
@@ -1507,7 +1507,13 @@ void ServiceWorkerRegistrar::ProfileStar
   nsAutoString blockerName;
   MOZ_ALWAYS_SUCCEEDS(GetName(blockerName));
 
-  rv = GetShutdownPhase()->AddBlocker(
+  nsCOMPtr<nsIAsyncShutdownClient> phase = GetShutdownPhase();
+  if (NS_WARN_IF(!phase)) {
+    NS_WARNING("Failed to get shutdown phase during profile startup");
+    return; // Skip registration if shutdown service isn't ready
+  }
+
+  rv = phase->AddBlocker(
       this, NS_LITERAL_STRING_FROM_CSTRING(__FILE__), __LINE__, blockerName);
   if (NS_WARN_IF(NS_FAILED(rv))) {
     return;

I get new crash:

Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
mozilla::IOUtils::EventQueue::SetShutdownHooks (this=0x7fffe122ab00) at ./xpcom/ioutils/IOUtils.cpp:2430
warning: 2430	./xpcom/ioutils/IOUtils.cpp: No such file or directory
(gdb) bt
#0  mozilla::IOUtils::EventQueue::SetShutdownHooks (this=0x7fffe122ab00) at ./xpcom/ioutils/IOUtils.cpp:2430
#1  0x00007fffe79a2fb0 in mozilla::IOUtils::State::SetShutdownHooks (this=0x7fffee593000 <mozilla::IOUtils::sState+8>) at ./xpcom/ioutils/IOUtils.cpp:2399
#2  mozilla::IOUtils::GetState () at ./xpcom/ioutils/IOUtils.cpp:2381
#3  0x00007fffe7997f8c in mozilla::IOUtils::WithPromiseAndState<mozilla::IOUtils::ReadJSON(mozilla::dom::GlobalObject&, nsTSubstring<char16_t> const&, mozilla::dom::ReadUTF8Options const&, mozilla::ErrorResult&)::$_0>(mozilla::dom::GlobalObject&, mozilla::ErrorResult&, mozilla::IOUtils::ReadJSON(mozilla::dom::GlobalObject&, nsTSubstring<char16_t> const&, mozilla::dom::ReadUTF8Options const&, mozilla::ErrorResult&)::$_0) (aGlobal=..., aError=<optimized out>, aFn=...) at ./xpcom/ioutils/IOUtils.cpp:320
#4  mozilla::IOUtils::ReadJSON (aGlobal=..., aPath=..., aOptions=..., aError=<optimized out>) at ./xpcom/ioutils/IOUtils.cpp:455
#5  0x00007fffe8f2fffc in mozilla::dom::IOUtils_Binding::readJSON (cx_=0x7fffe0540300, argc=1, vp=0x7fffd821a250) at ./IOUtilsBinding.cpp:2090
#6  0x00007fffe9709c14 in mozilla::dom::StaticMethodPromiseWrapper (cx=0x7fffe0540300, argc=3842286907, vp=0x7fffd821a250) at ./dom/bindings/BindingUtils.cpp:3341
#7  0x00007fffeb8b22c0 in CallJSNative (cx=0x7fffe0540300, native=0x7fffe9709bc0 <mozilla::dom::StaticMethodPromiseWrapper(JSContext*, unsigned int, JS::Value*)>, reason=<optimized out>, args=<optimized out>) at ./js/src/vm/Interpreter.cpp:494
#8  js::InternalCallOrConstruct (cx=<optimized out>, args=<optimized out>, construct=<optimized out>, reason=<optimized out>) at ./js/src/vm/Interpreter.cpp:590
#9  0x00007fffeb8b8b6c in InternalCall (cx=0x7fffe0540300, args=..., reason=<optimized out>) at ./js/src/vm/Interpreter.cpp:657
#10 js::CallFromStack (cx=0x7fffe0540300, args=..., reason=<optimized out>) at ./js/src/vm/Interpreter.cpp:662
#11 js::Interpret (cx=<optimized out>, state=<optimized out>) at ./js/src/vm/Interpreter.cpp:3286
#12 0x00007fffeb8b1ee4 in MaybeEnterInterpreterTrampoline (cx=0x7fffe0540300, state=...) at ./js/src/vm/Interpreter.cpp:395
#13 js::RunScript (cx=0x7fffe0540300, state=...) at ./js/src/vm/Interpreter.cpp:464
#14 0x00007fffeb8b25d8 in js::InternalCallOrConstruct (cx=<optimized out>, args=<optimized out>, construct=<optimized out>, reason=<optimized out>) at ./js/src/vm/Interpreter.cpp:622
#15 0x00007fffeb8b2b0c in InternalCall (cx=0x97e, args=..., reason=js::CallReason::CallContent) at ./js/src/vm/Interpreter.cpp:657
#16 js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=..., reason=<optimized out>) at ./js/src/vm/Interpreter.cpp:689
#17 0x00007fffeb92e264 in JS_CallFunctionValue (cx=<optimized out>, obj=..., fval=..., args=..., rval=...) at ./js/src/vm/CallAndConstruct.cpp:55
#18 0x00007fffe816faa8 in nsXPCWrappedJS::CallMethod (this=<optimized out>, methodIndex=<optimized out>, info=0x7fffe525e2c8 <xpt::detail::sMethods+31256>, nativeParams=<optimized out>) at ./js/xpconnect/src/XPCWrappedJSClass.cpp:918
#19 0x00007fffe798ab18 in PrepareAndDispatch (self=0x7fffe122aa60, methodIndex=<optimized out>, args=<optimized out>, gpregs=0x7ffffb9af760, fpregs=0x7ffffb9af7a0) at ./xpcom/reflect/xptcall/md/unix/xptcstubs_loongarch64.cpp:113
#20 0x00007fffe7989f7c in SharedStub () at /build/package/package/xpcom/reflect/xptcall/md/unix/xptcstubs_asm_loongarch64.S:43
#21 0x00007fffdcfb4ea0 in ??? ()

Both of the two crashes are nsIAsyncShutdownService related.

Comment 9

[Andreas Pehrson [:pehrsons]]

If that happens with a high frequency it must be some other underlying issue. Please file a new bug.