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

Steps to reproduce:

Open a couple tabs in firefox-nightly on sway-wayland and kept using Firefox. To capture any log, I started from commandline. Firefox nightly has been started with "env GDK_BACKEND=wayland MOZ_ENABLE_WAYLAND=1" in the Exec Argument with no change.

Actual results:

Firefox freezes.

Expected results:

Firefox is kept stable

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Thanks for the report!
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Getting_Mozilla_crash_report_from_running_or_frozen_Firefox
Please kill Firefox according to this tutorial. A crash reporter should open, please submit the report, then open about:crashes in Nightly, copy the crash id (bp-xxxxxxx) and post it here.

Are you really using latest Nightly or could it be one of the following bugs?
bug 1802327 has been fixed 2022-11-30.
bug 1795851 has been fixed 2022-12-07, but bug 1803016 still exists.
bug 1804973 has been fixed 2022-12-15.

Please try to find a regression range if possible:
$ pip3 install --upgrade mozregression
$ ~/.local/bin/mozregression --good 2022-12-01 --bad 2022-12-19 -a https://example.com -a https://example.org

So far no reproduction. Perhaps it will happen eventually again. It was reproducible all the time, thats why I reported it in the first place.

Firefox-nightly is frozen now. I cannot kill with signal of 11.

def@archlinux

OS: Arch Linux x86_64
Host: MS-7D51 1.0
Kernel: 6.0.12-arch1-1
Uptime: 2 days, 2 hours, 17 mins
Packages: 1116 (pacman), 32 (flatpak)
Shell: zsh 5.9
Resolution: 1920x1080
WM: sway
Theme: Adwaita [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: xfce4-terminal
Terminal Font: Inconsolata 16
CPU: AMD Ryzen 7 5800X3D (16) @ 3.400GHz
GPU: AMD ATI Radeon RX 6950 XT
Memory: 6452MiB / 32018MiB

1 % kill -s 11 $(pidof firefox-bin)

kill: unknown signal: SIG11
kill: type kill -l for a list of signals

(2) ~
1 % kill -l
HUP INT QUIT ILL TRAP IOT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

(2) ~
%

I installed /bin/kill from procps-ng and now I can invoke /bin/kill -s 11 $(pidof firefox-bin)

Heres the crashlog: https://crash-stats.mozilla.org/report/index/66889d41-ecc6-4a49-abfa-7833e0221220
bp-56df1361-b91d-4ce6-9e67-110ea0221220

Heres another crashlog happened when wanting to play back audio
bp-2a49c07e-abd0-4585-bfc8-19fad0221220

bp-2a49c07e-abd0-4585-bfc8-19fad0221220

[@ syscall | std::sys::unix::futex::futex_wait ]

Arch Linux

Thanks!
Do you have libx11 1.8.2? Please check if downgrading to libx11 1.8.1 avoids the problem. (bug 1801820)

I have 1.8.3-1, but I try 1.8.1-3.
Confuses me a bit why firefox uses libx11 under wayland. But I dont really know.

(Downgrading to libx11 1.8.1 didn't help in bug 1805939.)

Alright, then I try libx11 1.8.2

(In reply to a-development from comment #11)

Alright, then I try libx11 1.8.2

Please try 1.8.1.
1.8.2 caused bug 1801820. 1.8.3 might not have fully fixed it.

The bug has a crash signature, thus the bug will be considered confirmed.

libx11 1.8.1-3 did not help!

This time it happened when I was on a youtube instance, started a video, then turned on my audio device cause video would not play without audio device being turned on, then firefox froze. I wonder if it could be at all related.

bp-a4daab3c-2996-4b17-8965-cdead0221221

Would setting media.cubeb.sandbox_v2 to false on about:config and restarting Nightly prevent this problem? (bug 1792785)

(In reply to Darkspirit from comment #15)

Would setting media.cubeb.sandbox_v2 to false on about:config and restarting Nightly prevent this problem? (bug 1792785)

tried. I did set the value, opened a new tab and crash. I did not restart firefox. But I doubt it is the issue now!

bp-75a5db96-9558-461e-b831-1675c0221222

I wonder if those are the same? You remember I went through a libx11 downgrade... And today I got this awkward crash after changing the above..

I got a crash as well after changing that pref, I assume we have to ignore it because a restart is required. bug 1801049 is a regression of bug 1792785.

Its been sometime and it appeared less crashy. But it appears that this time it was close before a crash. The window would only update when the window state has been manually changed and only once, so it kept being frozen. I used the kill command to gather metrics. Have a look:

bp-17077eea-b6af-411d-a3ca-c4d5f0221226

I did not get any more crash after the change with "setting media.cubeb.sandbox_v2 to false".
However, sometimes I have to reload the page with f5 to get interact with some websites cause they wouldnt react otherwise... I think thats another issue.

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

For more information, please visit auto_nag documentation.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:karlt, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

The [@ syscall | std::sys::unix::futex::futex_wait ] crashes look like bug 1801049, which should now be fixed on Nightly with media.cubeb.sandbox_v2 at its default value of true. If this hang still occurs, then please reopen.

The [@ __poll ] signatures for hangs don't contain useful information, at least not on the crashing thread, because that is the expected state of the browser when idle.