1661398 - Early state callbacks (during stream init) may cause deadlock

Status: RESOLVED FIXED

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

Description

[Matthew Gregan [:kinetik]]

If a state_callback is triggered during stream_init (due to a backend initialization error), a deadlock may occur in the following situation:

1. Client calling thread (CubebOperation) calls stream_init, sends message to server, waits for response
2. Main server thread (AudioIPC Server) receives message, calls cubeb_stream_init and blocks waiting for initialization to complete
3. PulseAudio mainloop thread (threaded-ml) calls PulseStream::new::check_error and triggers CUBEB_STATE_ERROR due to a bad stream state
4. Server's state_callback (on threaded-ml) sends state error message to client, waits for response

Step 4 never completes because the machinery expected to hand the callback-related messages on the client side is only initialization after the stream_init in step 1 returns from the server.

This may be a PulseAudio backend specific issue, I haven't checked the other backends yet.

Comment 1

[Andreas Pehrson [:pehrsons]]

FWIW, A simple STR for this is, on linux without bug 1632864:

1. Load https://mozilla.github.io/webrtc-landing/gum_test.html
2. Click Microphone and approve the permission prompt
3. Unplug the microphone

(this should be enough to trigger the deadlock, but to observe the user-facing symptoms of it):
4. Load https://mozilla.github.io/webrtc-landing/gum_test.html
5. Click Microphone

Expected: A permission prompt, or if the permission is persistent, a playing media element
Actual: Nothing happens

Comment 2

[Matthew Gregan [:kinetik]]

Attachment: GitHub Pull Request

Comment 3

[Matthew Gregan [:kinetik]]

Fixed via bug 1672275.