Closed Bug 1449555 Opened 3 years ago Closed 3 years ago
Crash in static HRESULT `anonymous namespace'::get
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  to fix bug 1432779.  https://hg.mozilla.org/mozilla-central/rev?node=bca1660fc65c
I'd say it's something to do with https://github.com/kinetiknz/cubeb/commit/13d9e2874cb13ece4d14efcf34b086770f0bd624 which is what added that assertion. :kinetik?
Flags: needinfo?(jyavenard) → needinfo?(kinetik)
So either COM is not initialized consistently on the main thread, or this code is somehow running before COM initialization does. Before https://github.com/kinetiknz/cubeb/pull/424 (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
Status: NEW → ASSIGNED
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: https://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#2443 2. ContentChild starts the audio session when it receives the audio session data: https://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentChild.cpp#3199 3. COM initialized in STA during AudioSession::Start https://dxr.mozilla.org/mozilla-central/source/widget/windows/AudioSession.cpp#196
Also, even earlier in the content process startup: XRE_InitChildProcess -> 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: https://bugs.chromium.org/p/chromium/issues/detail?id=378465 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.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/16c170eb322b Update libcubeb to 7f4f3b6e. r=padenot
You need to log in before you can comment on or make changes to this bug.