Closed Bug 1449555 Opened 3 years ago Closed 3 years ago

Crash in static HRESULT `anonymous namespace'::get_default_endpoint


(Core :: Audio/Video: cubeb, defect, P2)

Windows 10



Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- fixed


(Reporter: calixte, Assigned: kinetik)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-e539b8d5-3f34-45d8-ae7e-7c16d0180328.

Top 10 frames of crashing thread:

0 xul.dll static HRESULT `anonymous namespace'::get_default_endpoint media/libcubeb/src/cubeb_wasapi.cpp:1065
1 xul.dll wasapi_init media/libcubeb/src/cubeb_wasapi.cpp:1154
2 xul.dll cubeb_init media/libcubeb/src/cubeb.c:216
3 xul.dll mozilla::CubebUtils::GetCubebContextUnlocked dom/media/CubebUtils.cpp:388
4 xul.dll mozilla::CubebUtils::GetCubebContext dom/media/CubebUtils.cpp:258
5 xul.dll mozilla::dom::AudioContext::Constructor dom/media/webaudio/AudioContext.cpp:208
6 xul.dll static bool mozilla::dom::AudioContextBinding::_constructor dom/bindings/AudioContextBinding.cpp:439
7 xul.dll static bool InternalConstruct js/src/vm/Interpreter.cpp:574
8 xul.dll js::ConstructFromStack js/src/vm/Interpreter.cpp:600
9 xul.dll static bool Interpret js/src/vm/Interpreter.cpp:3076


There is 1 crash in nightly 61 with buildid 20180327105613. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1432779.

Flags: needinfo?(jyavenard)
I'd say it's something to do with which is what added that assertion.

Flags: needinfo?(jyavenard) → needinfo?(kinetik)
Depends on: 1430704
Rank: 13
Priority: -- → P2
So either COM is not initialized consistently on the main thread, or this code is somehow running before COM initialization does.  Before (with bug 1445546), we would've blindly called CoInitializeEx(NULL, COINIT_MULTITHREADED) in this situation.

The long term fix for this is bug 1430704, so we can just avoid libcubeb API use from the main thread entirely.  In the mean time, we can plug this with some COM initialization in the right spot.
Assignee: nobody → kinetik
Flags: needinfo?(kinetik)
See Also: → 1445546
Not sure what's triggering this yet - unable to reproduce locally.

COM should be initialized on the main thread of the content process very early via:

1. ContentParent::InitInternal sends audio session data to content child:
2. ContentChild starts the audio session when it receives the audio session data:
3. COM initialized in STA during AudioSession::Start
Also, even earlier in the content process startup:

-> ContentProcess
   -> MainThreadRuntime
      -> STARegion

Every crash report I examined is a main thread crash.  There's no way we could be running the code that crashes before this initialization has run (or after it has uninitialized during shutdown), so there must be something else going on here.
The Chromium guys ran into a similar issue:

In that case they're running on a non-main-thread where COM was initialized in MTA but saw some installations (possibly with buggy third-party software running in process) failing CoCreateInstance with CO_E_NOTINITIALIZED.  They try to reinitialize COM.

Reinitializing COM inside libcubeb is tricky because we don't know which Gecko thread we're being called on.  We could scatter CoInitializeEx calls with Gecko thread checks around the libcubeb call sites, but it's not clear if the attempted reinitialization actually helps in these situations.  So I think the best solution for now is to remove the assert and turn this into a non-fatal error.
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.