1756733 - Firefox keeps freezing after suspending and resuming the machine - main thread blocks on CubebServer registration

Status: UNCONFIRMED

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

Description

[Ishan Jain]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

1. Start a firefox window.
2. Suspend machine with i3lock && systemctl suspend
3. Resume session
4. Open any website.
5. Right click on a link and open it in a new tab.
6. Freezes!

I only have Bitwarden, FF Containers and ublock origin extensions installed.

Actual results:

It should just open the link in a new tab

Expected results:

It freezes completely for a few seconds.

1. Firefox profiler result
   I suspend and resumed the machine. Started the profiler and then tried opening a link in a new tab. FF just froze for a few seconds. https://share.firefox.dev/3LX3mQr

2. strace logs of firefox
   It freezes at the line,

futex(0x7f8e93f1ae4c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0

Comment 1

[Ishan Jain]

Attachment: Firefox Troubleshooting data

Firefox troubleshooting data.

```

Comment 2

[Ishan Jain]

Correction,
It freezes at this line in strace logs.

socketpair(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0, [161, 183]) = 0
futex(0x7f8e93f1ae4c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0

Comment 3

[Ishan Jain]

Attachment: firefox.strace.txt

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 5

[Darkspirit]

Thanks for the report! Does this problem also occur with https://nightly.mozilla.org?

Comment 6

[Ishan Jain]

I can replicate this with firefox-nightly as well.

1. Installed firefox-nightly using, firefox-nightly AUR. firefox-nightly 99.0a1.20220208070047+ha25fb4010591-1
2. Started firefox-nightly like, firefox-nightly -profile $(mktemp -d -p /tmp).
3. Opened some random tabs.
4. Suspended machine
5. Resumed session
6. FF nightly keeps randomly freezing now.

In stdout/err, I see this.

[Child 17961, AudioIPC0] WARNING: 7fdfdfb237a0 StateCallback() state 0 cubeb error: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:666
[Child 17961, MediaDecoderStateMachine #1] WARNING: 7fdfdfb237a0 OpenCubeb() failed to init cubeb: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:286
[Child 17961, AudioIPC0] WARNING: 7fdfcf3fa010 StateCallback() state 0 cubeb error: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:666
[Child 17961, MediaDecoderStateMachine #1] WARNING: 7fdfcf3fa010 OpenCubeb() failed to init cubeb: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:286
[Child 17961, MediaDecoderStateMachine #1] WARNING: Decoder=7fdfcf0e8600 [OnMediaSinkAudioError]: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:4027
[GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
[Child 17961, AudioIPC0] WARNING: 7fdfced08010 StateCallback() state 0 cubeb error: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:666
[Child 17961, MediaDecoderStateMachine #1] WARNING: 7fdfced08010 OpenCubeb() failed to init cubeb: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:286
[Child 17961, MediaDecoderStateMachine #1] WARNING: Decoder=7fdfcdfe9400 [OnMediaSinkAudioError]: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:4027

I have a USB DAC plugged into the machine. When I suspend it, I see a failed to resume error -22 message from the USB subsystem.

I think I saw a recent bug in the linux kernel mailing list mentioning this suspend/resume issue with USB DACs.

Comment 7

[Darkspirit]

That firefox-nightly AUR is outdated (2022-02-08) and not an official build.
Edit: Sorry, that was partly a mistake, its source is today although the package version is older.

Is the hang also reproducible when launching Nightly with the following command? (it uses its own temporary profile by default)
$ pip3 install --user --upgrade mozregression
$ ~/.local/bin/mozregression --launch 2022-02-23 -a https://example.com -a https://example.net

If yes, please try to find a regression range in case it's a Firefox bug, you get a pushlog URL at the end:
$ ~/.local/bin/mozregression --good 2022-01-01 --bad 2022-02-23 -a https://example.com -a https://example.net

Comment 8

[Matthew Gregan [:kinetik]]

needinfo? reporter for Darkspirit's questions. Thanks!

Comment 9

[Ishan Jain]

Hi everyone!

There was a known issue in Linux kernel 5.16.10 which was causing problems in suspending/resuming USB DACs. I suspect that, After resuming Firefox would try to do something with audio devices and freeze because it would take too long to do whatever it needed with that device.

As per the patch notes of 5.16.11[1], A issue with usb-audio was resolved. Since 5.16.11, I have not had problems in suspending the device nor did I see any errors related to USB DAC when resuming the device.
After 5.16.11, Firefox also has not frozen once.

After I got the suggestion to run moz-regression, I tried to go back to 5.16.10 by rolling back linux, linux-firmware, linux-headers, nvidia, nvidia-utils, nvidia-settings but after doing that I couldn't get into the GUI. It kept freezing at the start up logs screen. I must be missing some package I need to rollback but I don't know which one it is.

Either way, I have not had this problem since 5.16.11 and currently, I am on 5.16.13. I guess somewhere in the code, Firefox does something related to audio in the "main" thread and freezes everything when the audio device is messed up and can't respond in a timely manner.

Please take your call on if this bug should be kept open.

[1] https://lwn.net/Articles/885894/

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:karlt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Karl Tomlinson (:karlt)]

I guess the main thread need not block on registration of the CubebServer.
The IPC call is already async.