From bug 1714779 comment 118

See thread 30 of the provided crash from sending SIGABRT
https://crash-stats.mozilla.org/report/index/cf0a3db0-dddf-452f-9de2-50f1e0210810

About support is here: https://gist.github.com/zealws/8bd97f620c853d8c62dbaa04cde0591f

zeal, can you post some links to some other crashes so we can confirm that the hang is always in the same place?

This is x11.
We have already seen GetBufferAge on xwayland: bug 1714567 comment 4 -> bug 1635186 comment 33 (Is this related to the Nvidia bug? bug 1716049)

I'm not sure if this is related to the nvidia bug, but I definitely don't have an nvidia card. I'm using an intel graphics card (on a laptop):

00:02.0 VGA compatible controller: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 2292
        Flags: bus master, fast devsel, latency 0, IRQ 164, IOMMU group 1
        Memory at e9000000 (64-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 2000 [size=64]
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: [40] Vendor Specific Information: Len=0c <?>
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [100] Process Address Space ID (PASID)
        Capabilities: [200] Address Translation Service (ATS)
        Capabilities: [300] Page Request Interface (PRI)
        Kernel driver in use: i915
        Kernel modules: i915

I'll submit a few more SIGABRT reports the next couple times it freezes and submit them here once I collect a few.

Here's 3 more crash reports:

https://crash-stats.mozilla.org/report/index/85984d81-8428-48bd-8b7c-91b850210811

https://crash-stats.mozilla.org/report/index/1c774dab-2c41-4a4b-83ac-a547f0210811

https://crash-stats.mozilla.org/report/index/ae4693ec-0abd-461a-9ef8-4cf960210811

Yeah, those are all in GLContextGLX::GetBufferAge()

I've filed an upstream Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5219. It's not obvious to me what might cause these hangs

So I noticed that firefox doesn't crash if it's on my secondary monitor... Maybe that's a clue of some type?

To explain:
I use a lenovo x1 carbon with a dock.
The dock has a large stand-alone screen connected via HDMI.
The carbon's laptop screen is a smaller monitor off to the side of the larger monitor.
Normally I keep firefox on the carbon's screen.
Firefox would crash repeatedly when it was on the smaller carbon screen (those 3 I linked were within an hour).
But since I moved it to the larger external screen, it hasn't crashed in the ~two hours I've had it here.

I'm wondering if something about the way organization of the two monitors has something to do with it?
Maybe it's something about regaining focus?

Fwiw, I have similar crashes on chromium and brave, too.

(In reply to zeal from comment #8)

...
Fwiw, I have similar crashes on chromium and brave, too.

That could point to an issue with the system compositor. Can you try a different desktop environment? Maybe Muffin, the Cinnamon window manager and compositor, is to blame here.

I'll give Gnome a try tomorrow and report back.

(In reply to Robert Mader [:rmader] from comment #9)

That could point to an issue with the system compositor.

A Xorg compositor can't affect this. It's between Firefox, Mesa and the Xorg driver (which one is being used here?).

How long does Firefox wait before it aborts?

(In reply to Michel Dänzer from comment #11)

A Xorg compositor can't affect this. It's between Firefox, Mesa and the Xorg driver (which one is being used here?).

How long does Firefox wait before it aborts?

Thanks, good to know. Zeal: you can check with xrandr --listproviders - it should say name:modesetting somewhere. If it says name:intel, that may be the issue. If it is, we should consider blocklisting HW-WR on everything but name:modesetting on mesa drivers IMO.

(In reply to Robert Mader [:rmader] from comment #12)

If it is, we should consider blocklisting HW-WR on everything but name:modesetting on mesa drivers IMO.

There should be no need to blocklist the non-generic drivers for AMD GPUs. Blocklisting specific broken drivers only would make more sense to me.

(In reply to Michel Dänzer from comment #13)

There should be no need to blocklist the non-generic drivers for AMD GPUs. Blocklisting specific broken drivers only would make more sense to me.

Yeah right. The intel driver has been quite notorious - and there's few reasons to still use it these days.

❯ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel

Been using KDE for about 4 hours this morning and so far no freezes. (Even with the intel DDX driver)

I removed the intel DDX driver, so next time I reboot I'll switch back to cinnamon and see if that fixes the issue.

Oh, I take it back, it crashed on KDE even. It happened right as I started playing around with the number of virtual desktops. :-/

https://crash-stats.mozilla.org/report/index/b08756be-647c-4b62-af30-780b20210812

I uninstalled the intel DDX driver (arch package: xf86-video-intel) and only kept the mesa driver installed (arch package: mesa) but neither Cinnamon nor KDE were able to launch applications, both launched blank windows.

Fwiw, I do not have an nvidia or amd graphics card to fall back to or use instead, I'm stuck with just the intel VGA card in my laptop.

(In reply to zeal from comment #17)

I uninstalled the intel DDX driver (arch package: xf86-video-intel) and only kept the mesa driver installed (arch package: mesa) but neither Cinnamon nor KDE were able to launch applications, both launched blank windows.

Hm, this sounds like a seriously broken setup. Zeal, any news here? Have you fixed the setup and do you know if switching to modesetting helps in any way?

The crashing stopped when I stopped using virtual desktops in cinnamon. I suspect something related to switching virtual desktops was causing the crash, but I haven't had further time to dig into it, and the issue hasn't re-occurred since.

I made a mental note to try out wayland and see if that improves things, but I haven't had time to try that either. For now I'm content with not using virtual desktops as a work-around.