Closed Bug 1267930 Opened 6 years ago Closed 6 years ago

crash in shutdownhang | `anonymous namespace'::stop_and_join_render_thread(cubeb_stream*)


(Core :: Audio/Video: cubeb, defect, P1)

47 Branch
Windows NT



Tracking Status
firefox49 --- fixed


(Reporter: jwwang, Assigned: padenot)



(Keywords: crash)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-621c109e-ea9b-4d66-a979-cafec2160420.

Thread 56
`anonymous namespace'::stop_and_join_render_thread(cubeb_stream*)

Thread 64
`anonymous namespace'::wasapi_stream_render_loop {
  mmcss_handle = stm->context->set_mm_thread_characteristics("Audio", &mmcss_task_index);

It looks like thread 64 is stuck.
Blocks: 1267752
We're blocked on something that should not really block, `set_mm_thread_characteristics`.

A possible solution here would be to not pass in INFINITE in `WaitForSingleObject`. In this case, we're shutting down, so we can leak the thread that's doing `set_mm_thread_characteristics`, it's not really an issue.
It's probably better to not TerminateThread here, because we don't really know
what happened down the stack of the rendering loop, so we just leak it. This
happens during shutdown so it's not really an issue, it's going to be cleaned
up by the OS anyways.

Review commit:
See other reviews:
Attachment #8745983 - Flags: review?(kinetik)
Rank: 12
Priority: -- → P1
Assignee: nobody → padenot
Comment on attachment 8745983 [details]
MozReview Request: Bug 1267930 - When the wasapi rendering loop is stuck and we're shuttin down, leak the thread and continue the shutdown process. r?kinetik

::: media/libcubeb/src/cubeb_wasapi.cpp:1183
(Diff revision 1)
>      LOG("Destroy SetEvent failed: %d\n", GetLastError());
>    }
> -  DWORD r = WaitForSingleObject(stm->thread, INFINITE);
> +  /* Wait one second for the rendering thread to return. It's supposed to check
> +   * its event loop very often, one second is rather conservative. */
> +  DWORD r = WaitForSingleObject(stm->thread, 1000);

Make it 5s just to be extra safe (and match the 5x1 timeout in the render loop), we generally shouldn't be hitting this so a long but non-infinite timeout is fine.
Attachment #8745983 - Flags: review?(kinetik) → review+
(also pushed upstream as 6194d5f4af9722e97084b5292a9f62a7f737a726).
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.