Closed Bug 1124411 Opened 5 years ago Closed 5 years ago

Deadlock in cubeb_wasapi backend

Categories

(Core :: Audio/Video, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox38 --- fixed

People

(Reporter: khuey, Assigned: padenot)

Details

Attachments

(2 files)

Attached file Stacks
See the attachment for stacks.  The audio backend appears to have deadlocked itself during shutdown (see the two wasapi threads) and one of them was holding the decoder monitor so that eventually deadlocks the main thread.
Which wasapi thread was holding the decoder monitor? I can't see it from the stack.
wasapi_stream_render_loop() stuck in WaitForMultipleObjects while wasapi_stream_stop() stuck in |WaitForSingleObject(stm->thread, INFINITE);| which happened after |SetEvent(stm->shutdown_event);| which should notify wasapi_stream_render_loop()... this is weird.
Yeah, I didn't really understand why the render_loop didn't quit.
Paul/Matthew: Any ideas?
Flags: needinfo?(padenot)
Flags: needinfo?(kinetik)
I've been re-reading this code, but it looks correct.

We could add a (rather high, like 1000ms) timeout to the WaitForMultipleObject (which is guaranteed to unblock at least every 30ms, and is on a very high priority thread), to see what happens. And maybe adding a assert somewhere where we could get the state of the stream in crash stats or something.
Flags: needinfo?(padenot)
Paul's idea sounds good to me.
Flags: needinfo?(kinetik)
Assignee: nobody → padenot
Status: NEW → ASSIGNED
Attachment #8565052 - Flags: review?(kinetik) → review+
https://hg.mozilla.org/mozilla-central/rev/c841c87a7791
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.