1838241 - Crash in [@ (anonymous namespace)::wasapi_stream_render_loop]

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/ec4831b2-2592-4691-a2ca-829320230612

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(stm->output_client || stm->input_client)

Top 7 frames of crashing thread:

0  xul.dll    media/libcubeb/src/cubeb_wasapi.cpp:1422
1  ucrtbase.dll  thread_start<unsigned int , 1>  
2  kernel32.dll  BaseThreadInitThunk  
3  mozglue.dll  mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>, void  const  toolkit/xre/dllservices/mozglue/nsWindowsDllInterceptor.h:150
3  mozglue.dll  patched_BaseThreadInitThunk  toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:616
4  ntdll.dll  __RtlUserThreadStart  
5  ntdll.dll  _RtlUserThreadStart  

There are several crashes under this signature but the interesting ones are those with MOZ_RELEASE_ASSERT(stm->output_client || stm->input_client) in the MozCrashReason. They seem to have started recently from what I can tell.

Comment 1

[Gabriele Svelto [:gsvelto]]

The first affected buildid appears to be 20230522162825. See this nightly crash.

Comment 2

[Paul Adenot (:padenot)]

Probably a regression from https://github.com/mozilla/cubeb/commit/febf49d0898d1c1691235639b0796b91df522394.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:kinetik, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Jim Mathies [:jimm]]

Paul, can you pick this up? Also might be related to Bug 1843903

Comment 5

[Matthew Gregan [:kinetik]]

(In reply to Paul Adenot (:padenot) from comment #2)

Probably a regression from https://github.com/mozilla/cubeb/commit/febf49d0898d1c1691235639b0796b91df522394.

Before this change, cubeb would destroy the render thread when the stream was stopped (and recreate it when the stream was started). After this change, the render thread exists for the entire lifetime of the stream (even when the stream is stopped). It appears cubeb is now trying to handle a device reconfiguration event on the render thread in situations where the stream is stopped, and in the crash reports I looked at this is racing with a stream_start called from another thread.

stream_start will handle device reconfiguration directly if necessary, so I think all that's necessary to address this is to avoid handling device reconfiguration events on the render thread for stopped streams.

Comment 6

[Matthew Gregan [:kinetik]]

Attachment: GitHub Pull Request

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1833633

Comment 8

[Ryan VanderMeulen [:RyanVM]]

I guess this is another "fixed by an upstream libcubeb update" bug we need to keep on the ESR115 radar.

Comment 9

[Paul Adenot (:padenot)]

I've outlined what we need to do in https://bugzilla.mozilla.org/show_bug.cgi?id=1845499#c6 because there are a couple fixes that needs to be picked up as well to get the full fix.

We can also carve out the windows-only part here if need be.