You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like I have the basis of a lockup when capture devices are used in Firefox, and this is the smallest reproducable test case I am able to create from the browser.
On Linux with apulse, this is often (but not always) leaving some kind of lock held:
the Firefox UI can do basic operations but not a lot else.
Other apps continue to be able to record the same "dsnoop" device.
Firefox has do be killed with a soft SIGINT to restore most of its functionality; "pkill firefox-bin".
Other platforms seem immune; Mac and Windows.
With experimentation it looks like it's an interaction between opening both playback and capture devices. With capture only I wasn't able to show the result. It could be races on the fast opening/closing when error conditions occur.
The firefox process is left with a thread in this state:
Thread 46 (Thread 0x7fc3c17fe700 (LWP 14599)):
#0 0x00007fc3e364036f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1 0x00007fc3b6dc8ea7 in pa_threaded_mainloop_wait () at /usr/lib64/apulse/libpulse.so.0
#2 0x00007fc3d3b1b066 in _$LT$cubeb_pulse..backend..stream..PulseStream$u20$as$u20$cubeb_backend..traits..StreamOps$GT$::stop::h0b3214cf8c1e02c3 () at /scratch/mark/tmp/ff/firefox/libxul.so
#3 0x00007fc3d3b14bda in cubeb_backend::capi::capi_stream_stop::h148e9408bfd40feb () at /scratch/mark/tmp/ff/firefox/libxul.so
#4 0x00007fc3d3c4ba1a in cubeb_core::stream::StreamRef::stop::ha9e7c2fa562d26f8 () at /scratch/mark/tmp/ff/firefox/libxul.so
#5 0x00007fc3d3bc76c5 in audioipc_server::server::CubebServer::process_msg::h089c041680ef1cdb () at /scratch/mark/tmp/ff/firefox/libxul.so
#6 0x00007fc3d5859663 in _$LT$audioipc_server..server..CubebServer$u20$as$u20$audioipc..rpc..server..Server$GT$::process::he0be6d27a49be39a () at /scratch/mark/tmp/ff/firefox/libxul.so
#7 0x00007fc3d5855e5b in _$LT$futures..future..map_err..MapErr$LT$A$C$F$GT$$u20$as$u20$futures..future..Future$GT$::poll::h563291d28ca3169b () at /scratch/mark/tmp/ff/firefox/libxul.so
#8 0x00007fc3d5853067 in tokio::runtime::current_thread::runtime::Runtime::block_on::hd21a8602f581c25d () at /scratch/mark/tmp/ff/firefox/libxul.so
#9 0x00007fc3d3bbbac4 in std::sys_common::backtrace::__rust_begin_short_backtrace::hfab3e639f9165888 () at /scratch/mark/tmp/ff/firefox/libxul.so
#10 0x00007fc3d3bbd5c7 in core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h6ace096c9215fb5d () at /scratch/mark/tmp/ff/firefox/libxul.so
#11 0x00007fc3d5a7793a in std::sys::unix::thread::Thread::new::thread_start::h5ad4ddffe24373a8 () at /scratch/mark/tmp/ff/firefox/libxul.so
#12 0x00007fc3e363a684 in start_thread () at /lib64/libpthread.so.0
#13 0x00007fc3e28d0eed in clone () at /lib64/libc.so.6
I note that pulseaudio is deferring work to its own worker threads. They are in this state, so I can reasonably see why nothing is moving forward:
Thread 83 (Thread 0x7fc3b44ff700 (LWP 14756)):
#0 0x00007fc3e28c52fd in poll () at /lib64/libc.so.6
#1 0x00007fc3b6dc8c1a in poll_func () at /usr/lib64/apulse/libpulse.so.0
#2 0x00007fc3b6dc4f1e in pa_mainloop_poll () at /usr/lib64/apulse/libpulse.so.0
#3 0x00007fc3b6dc4c31 in pa_mainloop_iterate () at /usr/lib64/apulse/libpulse.so.0
#4 0x00007fc3b6dc52a5 in pa_mainloop_run () at /usr/lib64/apulse/libpulse.so.0
#5 0x00007fc3b6dc8bc2 in mainloop_thread () at /usr/lib64/apulse/libpulse.so.0
#6 0x00007fc3e363a684 in start_thread () at /lib64/libpthread.so.0
#7 0x00007fc3e28d0eed in clone () at /lib64/libc.so.6
Thread 76 (Thread 0x7fc3b6abf700 (LWP 14743)):
#0 0x00007fc3e28c52fd in poll () at /lib64/libc.so.6
#1 0x00007fc3b6dc8c1a in poll_func () at /usr/lib64/apulse/libpulse.so.0
#2 0x00007fc3b6dc4f1e in pa_mainloop_poll () at /usr/lib64/apulse/libpulse.so.0
#3 0x00007fc3b6dc4c31 in pa_mainloop_iterate () at /usr/lib64/apulse/libpulse.so.0
#4 0x00007fc3b6dc52a5 in pa_mainloop_run () at /usr/lib64/apulse/libpulse.so.0
#5 0x00007fc3b6dc8bc2 in mainloop_thread () at /usr/lib64/apulse/libpulse.so.0
#6 0x00007fc3e363a684 in start_thread () at /lib64/libpthread.so.0
#7 0x00007fc3e28d0eed in clone () at /lib64/libc.so.6
The text was updated successfully, but these errors were encountered:
It looks like I have the basis of a lockup when capture devices are used in Firefox, and this is the smallest reproducable test case I am able to create from the browser.
On Linux with apulse, this is often (but not always) leaving some kind of lock held:
Other platforms seem immune; Mac and Windows.
With experimentation it looks like it's an interaction between opening both playback and capture devices. With capture only I wasn't able to show the result. It could be races on the fast opening/closing when error conditions occur.
The firefox process is left with a thread in this state:
I note that pulseaudio is deferring work to its own worker threads. They are in this state, so I can reasonably see why nothing is moving forward:
The text was updated successfully, but these errors were encountered: