Created attachment 8552700 [details] 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.
The one calling wasapi_stream_stop. http://hg.mozilla.org/mozilla-central/annotate/34e2d2bd7ec4/dom/media/AudioSink.cpp#l200
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?
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.
Paul's idea sounds good to me.
Created attachment 8565052 [details] [diff] [review] Add timeout when calling WaitForMultipleObjects to wallpaper over a deadlock. r=
Attachment #8565052 - Flags: review?(kinetik)
Assignee: nobody → padenot
Status: NEW → ASSIGNED
Attachment #8565052 - Flags: review?(kinetik) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox38: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.