Crash in [@ IPCError-browser | ShutDownKill | RtlAcquireSRWLockExclusive | mozilla::MediaTrackGraphImpl::InterruptJS]
Categories
(Core :: Audio/Video: MediaStreamGraph, defect)
Tracking
()
People
(Reporter: alex_mayorga, Unassigned)
Details
(Keywords: crash, nightly-community)
Crash Data
This bug is for crash report bp-c2e15a05-97fd-4b2c-9c2b-340d80200717.
Top 10 frames of crashing thread:
0 ntdll.dll NtWaitForAlertByThreadId
1 ntdll.dll RtlAcquireSRWLockExclusive
2 xul.dll mozilla::MediaTrackGraphImpl::InterruptJS dom/media/MediaTrackGraph.cpp:3666
3 xul.dll mozilla::dom::AudioContext::OnWindowDestroy dom/media/webaudio/AudioContext.cpp:788
4 xul.dll nsGlobalWindowInner::FreeInnerObjects dom/base/nsGlobalWindowInner.cpp:1139
5 xul.dll nsGlobalWindowOuter::DetachFromDocShell dom/base/nsGlobalWindowOuter.cpp:2647
6 xul.dll nsDocShell::Destroy docshell/base/nsDocShell.cpp:4199
7 xul.dll nsWebBrowser::SetDocShell toolkit/components/browser/nsWebBrowser.cpp:1131
8 xul.dll nsWebBrowser::InternalDestroy toolkit/components/browser/nsWebBrowser.cpp:174
9 xul.dll nsWebBrowser::Destroy toolkit/components/browser/nsWebBrowser.cpp:855
¡Hola!
I had to use crashfirefox64.exe on a hung Firefox Nightly again today.
Hope this report is useful.
¡Gracias!
Alex
|
||
Comment 1•4 years ago
|
||
Thanks for the report. This looks to have the same root cause as bug 1653113.
Thread 11 is an interesting one holding the graph monitor while calling into cubeb/audioipc.
I wonder whether audioipc is not responding while Thread 26 does not return from the cubeb data callback, waiting on Thread 27, which is waiting for the graph monitor.
The stack seems to be missing some audioipc frames in Thread 11, and I'm not familiar with that code, so I'm having trouble working out what audioipc is waiting on.
Hopefully this is avoided by https://hg.mozilla.org/integration/autoland/rev/38dc6c6d4d14, but please link to a more recent crash report if there is a similar issue in the latest Nightly.
Description
•