Firefox hangs after ending Google Meet, deadlock on `pa_threaded_mainloop_wait`

[Svalorzen]

This hang is essentially guaranteed on my end. When a google meet ends, and I close the tab, after a couple of seconds Firefox hangs. It happens too in some other cases, but this is the most consistent one. I finally took some time to get some traces:

Thread 69 (Thread 0x7185fa2ff6c0 (LWP 5820) "AudioIP~ver RPC"):
#0  0x0000718676298d71 in __futex_abstimed_wait_common64 (private=115125, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7185d8fd3dbc) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=115125, abstime=0x0, clockid=0, expected=0, futex_word=0x7185d8fd3dbc) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7185d8fd3dbc, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x000071867629b7ed in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7185d8fd3d68, cond=0x7185d8fd3d90) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7185d8fd3d90, mutex=0x7185d8fd3d68) at ./nptl/pthread_cond_wait.c:627
#5  0x000071862de09b6d in pulse_ffi::ffi_funcs::dynamic_fns::pa_threaded_mainloop_wait () at /build/firefox-s4eP1H/firefox-145.0+build2/third_party/rust/pulse-ffi/src/ffi_funcs.rs:1649
#6  pulse::threaded_mainloop::ThreadedMainloop::wait () at /build/firefox-s4eP1H/firefox-145.0+build2/third_party/rust/pulse/src/threaded_mainloop.rs:62
#7  cubeb_pulse::backend::stream::{impl#6}::stop () at src/backend/stream.rs:655
#8  cubeb_backend::capi::capi_stream_stop<cubeb_pulse::backend::stream::PulseStream> () at /build/firefox-s4eP1H/firefox-145.0+build2/third_party/rust/cubeb-backend/src/capi.rs:296
#9  0x000071862dc3bfae in cubeb_core::stream::StreamRef::stop () at /build/firefox-s4eP1H/firefox-145.0+build2/third_party/rust/cubeb-core/src/call.rs:16
#10 audioipc2_server::server::CubebServer::process_msg () at src/server.rs:560

Thread 28 (Thread 0x7185ea1fd6c0 (LWP 6394) "AudioIP~ver RPC"):
#0  0x000071867631b4fd in __GI___poll (fds=0x7185f02d68a0, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007185f7af2ce0 in poll_func () at /usr/local/lib/apulse/libpulse.so.0
#2  0x00007185f7aefc2d in pa_mainloop_iterate () at /usr/local/lib/apulse/libpulse.so.0
#3  0x00007185f7aefc82 in pa_mainloop_run () at /usr/local/lib/apulse/libpulse.so.0
#4  0x00007185f7af2d36 in mainloop_thread () at /usr/local/lib/apulse/libpulse.so.0
#5  0x000064a167230a38 in set_alt_signal_stack_and_start (params=<optimized out>) at /build/firefox-s4eP1H/firefox-145.0+build2/mozglue/interposers/pthread_create_interposer.cpp:81
#6  0x000071867629caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#7  0x0000718676329c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

I'm not sure whether a fix could be hacked by just adding a timer to the waiting function, or if there's some more info I could help debug. I'm not sure if adding tracing here might help, given that it's just a deadlock.

[Svalorzen]

Ah, this is probably #118