Frequent crashes on Firefox

English Applications
,
1

I am experiencing frequent crashes in Mozilla Firefox 149.0 (OpenSuse repos) and have been unable to reproduce them reliably.
When checking the crash report consistently an issue with libgallium-26.0.4 is shown, reason is SIGBUS / BUS_ADRERR:

I unfortunately don’t have the necessary knowledge to discern whether this is a Firefox issue, an issue in Mesa or maybe a sign of some hardware issue.
Here is the relevant system information:

Operating System: openSUSE Tumbleweed 20260405
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.11.0
Kernel Version: 6.18.21-1-longterm (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 16 GiB of RAM (15.5 GiB usable)

I have a dual GPU setup: Nvidia 1050, and CoffeeLake-H GT2 [UHD Graphics 630], though it should be using the latter.

Let me know in case I am missing some critical information.

Have a nice day and thank you in advance

2

It appears like you are using Mesa packages from packman. Test with the distribution packages and make sure that ALL Mesa packages are from the same source.

1 Like
3

I was advised to check first with GDB, I have no idea how to operate it or read the output, however.

4

You as a normal user have no chance to debug anything with GDB, let alone something as complex as Firefox. That’s like attempting to heal somebody’s brain tumor with a screwdriver.

Follow @hui’s advice: Restore the foundation that Firefox operates on to a well-defined status, i.e. use the standard packages that belong to the distribution, not third-party packages like those from PackMan. That will most likely resolve the problem.

2 Likes
5

I can try, but there is a reason for me to be using Packman codecs.

6

Consider it a troubleshooting step … it’s potentially a way to determine where the issue is. (you did come here for hints how to solve your issue :+1: )

1 Like
7

Sure. I didn’t want to seem ungrateful. Is there a clean way to switch back to the standard packages?

8
  1. Disable the Packman repo (easy enough to enable it again after the test).
  2. zypper dup -- from <Alias, Name or # of your OSS repo> --allow-vendor-change
1 Like
9

Than you should read the wiki how to add only the codecs and not the Mesa stuff…
https://en.opensuse.org/SDB:Installing_codecs_from_Packman_repositories

But first get a clean system without packman to troubleshoot your Firefox issue.

1 Like
10

As far as for that’s concerned: I am completely confused, I have been given contradictory information. As far as I know, I only got the codecs, nothing else (I mean that all I did was use opi codecs). On Myrlin, Mesa packages are ticked as both in Packman and normal repos.

imagen
imagen1212×718 173 KB

imagen
imagen1212×718 197 KB

The information I am mentioning is from a Project Member from the discord. That was the person who advised me to use GDB.

11

opi shouldn‘t be used as it makes it possible to install packages from home/devel/experimental/incompatible repos. It makes it really easy for inexperienced users to break the system.

And as you can easily see at your screenshot, you have Mesa from packman…

1 Like
12

Okay, but why are they ticked in oss too? And I do know the risks of Opi.

13

In the “Repositories” view, Myrlyn shows a package in the list for each of the repositories that has a version of that package. But that doesn’t mean that you have the package installed from that repository; only that there is at least one version from it.

Switch to the “Versions” tab at the lower right to see all the versions; the topmost version shows the installed one and from what vendor (here: openSUSE or PackMan) it came from, and below it shows all the available versions:

Myrlyn-versions
Myrlyn-versions1684×1033 221 KB

For PackMan packages especially, it’s even easy to spot directly in the package list: The version column (“Installed(Available)”) shows a .pm.\ for “PackMan”.

In this example, I have ‘vlc’ and its dependent packages from the openSUSE repo, but I could also install it from the PackMan repo, so they show up in both the “Packman” and the “Slowroll OSS Repo” here.

1 Like
14

I see. Thank you for the explanation, appreciate you putting in the time to clarify this.
The only issue I still see is that since I can’t reproduce consistently, it will be a bit of stabbing in the dark. I’ll also throw this in from the backtrace, in case it might be useful in some way:

Core was generated by `/usr/lib64/firefox/firefox'.
Program terminated with signal SIGBUS, Bus error.
#0  0x00007fb8b4a29248 in disk_cache_has_key (cache=0x7fb8a7d14230, 
    key=0x7fb89eba05d0 "z\242\333\024\017z\031@\210G\252\350\354\245{\022^K<e\264Be^I\340\211.)\233z?\232w!\337U\020~\0371\177\327\356;;\266\"_\225p\3408~\345\337\225y\365\020AdG\374")
    at ../src/util/disk_cache.c:680

warning: 680    ../src/util/disk_cache.c: No such file or directory

I apologise if this has been a bit frustrating or annoying, like I said I was told by other project members to try other things before messing with vendor changes. Might not seem like it but I am not completely new to Linux, though I am pretty new to OpenSuse

15

You might want to link to this other threads…
This sounds not quite right.

16

Chrome-based browsers use a feature called, “GPU Cache”. It’s very well known to clear that cache when rendering results in crashes.

Rumors are that Firefox uses a similar GPU cache.

Here’s a simple troubleshooting step. Create a brand new user account. Now, log out of your regular user account, then log into the new user account . DO NOT import FF data from your regular account… start FF and then visit all those websites that cause crashes.

Still see the same issue ??

17

Google AI suggests to delete the Firefox cache:

rm -rf ~/.cache/mozilla/firefox

Since I move my Firefox cache to a RAM disk on a regular basis, I can confirm that nothing bad happens when you do that. It’s worth a try.

18

I wont use FF, but my research about the FF “GPU” cache (location) is not what you suggest.

It’s like the Chrome based “GPU” cache sub-dir location … this is not the “where I browse to on the 'Net all the time” cache… it’s used by the GPU for performance rendering.

19

I used to use TW. And it was very common that the Chrome browsers I use (Chrome and Brave) would end up with crashes and rendering probs (after a zypper dup)

So, I would run a script I wrote that searched for the various Chrome GPUCache sub-directories and clear them out … then restart the browsers and they would work fine. (posts easily found in a search in this forum).

Anyway, here’s how we find the GPUCache sub-dir for Chrome (and surprisingly other non-Chrome apps) … I think the FF GPU cache sub-dir is “cache2”, but don’t trust me.

For Chrome browsers, simply change into that GPUCache sub-dir, then delete its content.

Not sure for Firefox… I will say, it’s a remote possibility based on subtle (not very specific) errors shown.

user@machine :~> find . -type d -name GPUCache* -ls
drwx------ 58 Mar 26 18:21 ./.config/BraveSoftware/Brave-Browser/Default/GPUCache
drwx------ 90 Apr  8 10:08 ./.config/BraveSoftware/Brave-Browser-Beta/Default/GPUCache
drwx------ 58 Mar 17 10:49 ./.config/google-chrome/Default/GPUCache
drwx------ 58 Feb 17  2025 ./.config/chromium/Default/GPUCache

drwx------  0 Oct 26 20:22 ./.local/share/openSUSE/org.opensuse.opensuse_welcome/QtWebEngine/Default/GPUCache
drwx------  0 Oct 26 20:23 ./.local/share/ark/QtWebEngine/Default/GPUCache
drwx------ 58 Mar 28 20:30 ./.local/share/konqueror/QtWebEngine/Default/GPUCache
drwx------  0 Oct 26 20:24 ./.local/share/digikam/QtWebEngine/Default/GPUCache
drwx------ 58 Nov 20 22:58 ./.local/share/kontact/QtWebEngine/Default/GPUCache
drwx------ 58 Nov  8 19:39 ./.local/share/kioslave5/QtWebEngine/Default/GPUCache
user@machine :~>
20

Try downloading Firefox from Mozilla, run ‘’‘firefox-bin’‘’ from the folder and see if you have the same issue.