1762581 - Hang when visiting about:support hung up in cubeb

Status: RESOLVED WORKSFORME

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

Description

[Emilio Cobos Álvarez [:emilio]]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/60553a3a-e817-450f-8e80-3283b0220401

Reason: SIGSEGV / SI_USER

Top 10 frames of crashing thread:

0 libc.so.6 __futex_abstimed_wait_common 
1 libc.so.6 __GI___pthread_cond_wait 
2 libxul.so futures::task_impl::std::ThreadNotify::park /build/firefox/src/firefox-98.0.2/third_party/rust/futures-0.1.31/src/task_impl/std/mod.rs:516
3 libxul.so futures::future::Future::wait /build/firefox/src/firefox-98.0.2/third_party/rust/futures-0.1.31/src/future/mod.rs:300
4 libxul.so <audioipc_client::context::ClientContext as cubeb_backend::traits::ContextOps>::max_channel_count /build/firefox/src/firefox-98.0.2/third_party/rust/audioipc-client/src/context.rs:262
5 libxul.so cubeb_backend::capi::capi_get_max_channel_count /build/firefox/src/firefox-98.0.2/third_party/rust/cubeb-backend/src/capi.rs:85
6 libxul.so mozilla::CubebUtils::MaxNumberOfChannels /build/firefox/src/firefox-98.0.2/dom/media/CubebUtils.cpp:739
7 libxul.so nsDOMWindowUtils::GetCurrentMaxAudioChannels /build/firefox/src/firefox-98.0.2/dom/base/nsDOMWindowUtils.cpp:2665
8 libxul.so NS_InvokeByIndex 
9 libxul.so XPCWrappedNative::CallMethod /build/firefox/src/firefox-98.0.2/js/xpconnect/src/XPCWrappedNative.cpp:1130

A friend of mine can consistently reproduce this freeze when visiting about:support. I told him to kill -11 $(pidof firefox) to get this crash report. Paul, do you know what might be going on, or if not do you know who would?

Comment 1

[Emilio Cobos Álvarez [:emilio]]

The "AudioIPC Server RPC" thread and "BackgroundThreadPool #3" are also doing cubeb things.

Comment 2

[Paul Adenot (:padenot)]

We're doing audio things in about:support there to gather info about the system's audio capabilities, in terms of devices, latencies, etc.

Emilio, is audio working ok on this system, generally, do you know?

It may be that we're doing a few things concurrently (gathering input/output latency figures, gathering device list, getting the max channels count), and we're breaking an audioipc assumption or something? This is slightly unusual in the sense that it's directly from the parent process. Matthew, do you have an idea?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Yes, I was told that audio was working fine.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Matthew, is there some code we can add to make this more actionable? Do we know what thread we're waiting for?

Comment 5

[BugBot [:suhaib / :marco]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 6

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.