Crash in [@ IPCError-browser | ShutDownKill | RtlAcquireSRWLockExclusive | mozilla::MediaTrackGraphImpl::RunInStableState]
Categories
(Core :: Audio/Video, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | wontfix |
firefox78 | --- | wontfix |
firefox79 | --- | wontfix |
firefox80 | --- | fixed |
People
(Reporter: alex_mayorga, Assigned: padenot)
References
(Regression)
Details
(Keywords: crash, nightly-community, regression)
Crash Data
Attachments
(3 files)
This bug is for crash report bp-6f94dfd6-438d-49bf-a311-212a70200715.
Top 10 frames of crashing thread:
0 ntdll.dll NtWaitForAlertByThreadId
1 ntdll.dll RtlAcquireSRWLockExclusive
2 xul.dll mozilla::MediaTrackGraphImpl::RunInStableState dom/media/MediaTrackGraph.cpp:1684
3 xul.dll mozilla::`anonymous namespace'::MediaTrackGraphStableStateRunnable::Run dom/media/MediaTrackGraph.cpp:1647
4 xul.dll mozilla::CycleCollectedJSContext::AfterProcessTask xpcom/base/CycleCollectedJSContext.cpp:467
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1271
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:513
7 xul.dll mozilla::jsinspector::nsJSInspector::EnterNestedEventLoop devtools/platform/nsJSInspector.cpp:74
8 xul.dll XPTC__InvokebyIndex
9 @0xc2bdff9c77
¡Hola!
This was generated with crashfirefox64.exe on a hung Firefox nightly.
Please let me know if there's anything needed from the affected system.
¡Gracias!
Alex
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
David, does the very last stack frame (that seem to be present on quite a few threads) means something? The browser was completely frozen before right before this (see 1653112).
Assignee | ||
Comment 2•4 years ago
|
||
Appeared in the last month as well, weird.
(In reply to Paul Adenot (:padenot) from comment #1)
David, does the very last stack frame (that seem to be present on quite a few threads) means something? The browser was completely frozen before right before this (see 1653112).
Well, it means that a lot of threads are waiting, which is likely totally fine behavior for N-2 of those threads. The key is to find which two are waiting on each other. I see MediaTrack
frames near the lock frames on several threads, and in general the words EnterNestedEventLoop
give me the async heebie-jeebies, so that might be a good place to start.
Assignee | ||
Comment 4•4 years ago
|
||
This seems to be a deadlock at the intersection of audioipc, the MTG and cubeb. I'm fixing this by backing out most of 1628779, except the cubeb bits.
Assignee | ||
Comment 5•4 years ago
|
||
Depends on D83651
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D83804
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D83805
Assignee | ||
Comment 8•4 years ago
|
||
I'll note that I'm keeping the other patches, because I still want to have the section in about:support
for the latency.
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•