1793979 - Firefox Nightly repeatedly exiting when using audio conferencing.

Status: RESOLVED WORKSFORME

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

Description

[nemo]

For the past couple of days, after updating my nightly, I have been getting repeated exits of the entire application when using Jitsi (audio only) and voice.google.com (web phone calls).

It appears to happen randomly, but might be related to activity elsewhere in Firefox (that is, it seemed better behaved if I was working in other apps, but could be my imagination).

It would exit as quickly as after a few minutes, or last for a quarter of an hour.

On exit, I saw this on STDERR.

Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
CPU time limit exceeded

Those messages seem consistent in all cases, although I do not know if they are significant.

Repeated updates of nightly did not seem to resolve, nor did updating and restarting my system, so I figured I'd better report it.

Comment 1

[Karl Tomlinson (:karlt)]

If you enter about:crashes in the url bar, are there any recent crash reports?

Comment 2

[nemo]

No, that was the first thing I checked ☺

No crashes.

It's still going on, just happened a few minutes ago when I forgot to run the Jitsi Meet in Devuan ESR 102..

I did see an odd thing in dmesg rechecking it for any hints of hardware issues, but, it was from 2½ days ago so probably not related.
[603766.658576] Isolated Web Co[7019]: segfault at 0 ip 00007f800cf9e7e3 sp 00007ffe4cbbd260 error 6 in libxul.so[7f8007e47000+5f66000]
(plus a code line but I decided to omit on off-chance it had anything sensitive)

But yeah, it's very reproducible for me, and seems to have that "Exiting due to channel error."

Comment 3

[Karl Tomlinson (:karlt)]

"Exiting due to channel error" may be the child processes exiting because the parent process has crashed.
"CPU time limit exceeded" is SIGXCPU, which would explain the lack of crash reports.
Experimenting with

systemctl disable rtkit-daemon.service
systemctl stop rtkit-daemon.service

would confirm that SIGXCPU is the source of the crash.

Paul, Matthew: know of any recent changes around realtime threads, probably in the browser process?

Comment 4

[Matthew Gregan [:kinetik]]

AudioIPC v2 was enabled for Linux in nightly-only builds in bug 1792785 (from 2022-09-30 on).

nemo, can you please let us know whether the crash still occurs after the preference media.cubeb.sandbox_v2 is set to false in about:config? (note: browser restart required after changing the pref value)

Comment 5

[nemo]

I disabled the sandbox pref. I'll see if the issue repeats tomorrow in work jitsi sessions. I'm idling in one now, but it might require a bit more going on.

Comment 6

[nemo]

Ever since disabling that sandbox pref, the issue has not reproduced.

Comment 7

[Matthew Gregan [:kinetik]]

Thanks for testing and confirming! This feature is nightly-only for now. I suspect this bug has a similar root cause to bug 1792753 on Windows. I'll get a fix landed for that bug this week-ish and see if it solves your issues on Nightly, if not we may need additional info from you to track this down.

Comment 8

[nemo]

Ok... just let me know when to retest.

Comment 9

[nemo]

Given the activity on the other bug and the fact that it's worked reliably for me for a while now without the sandbox deactivation, I'm going to close this.