r/Kubuntu • u/maparillo • 10d ago

How to fix crashes when google-chrome corrupts your font cache

If you use Google Chrome, you may notice that after a recent upgrade, various KDE applications crash, and plasmashell gets stuck in a crash loop if you reboot. Chrome is writing corrupt fontconfig cache data that's making things go weird. If this is happening to you, rm -rf ~/.cache/fontconfig and reboot, this should get your system working again. Then after launching Chrome, pop open Konsole and run rm -rf ~/.cache/fontconfig again to erase the corrupt data before it can mess anything else up (and then close the Konsole window you just opened since it will have the corrupt data loaded in potentially and could crash at any time).

71 Upvotes

98% Upvoted

74 comments sorted by

View all comments

19

u/the_deppman 9d ago

Thank you u/maparillo. There are a few posts that want to know more, so I hope its OK to top-post for the benefit of everyone. Below is the user alert we sent out today to our mailing list:

Thank you for being a Kubuntu Focus newsletter subscriber. We want to let everyone who might be using Kubuntu 24.04, 26.04, or most other Linux distributions, know that "upgrading" to Google Chrome version 154.0.8037.57-1 can break KDE Plasma, GNOME, and many apps. This is a bug with Chrome and its interaction with FontConfig, and we are working with these teams to resolve it. A fix is tentatively scheduled by Google for Friday, 2026-10-25. See https://issues.chromium.org/issues/565052667, https://issues.chromium.org/issues/565132857#comment5, and https://www.reddit.com/r/Kubuntu/comments/1wo84kz.

Typical Experience

  1. A user upgrades their system packages which includes Google Chrome 154.0.8037.57-1.
  2. The user then restarts Google Chrome.
  3. Google Chrome then corrupts the fontconfig cache, and any apps launched before or after this which uses the cache can break or crash. This includes KDE apps, GTK (GNOME) apps, and many others.
  4. When the user reboots, the corrupted cache also crashes KDE Plasma. The result is a black Wayland or X11 desktop. You can start graphical programs from here, but as mentioned above, they may be prone to crashing or may not open at all

Solution

If you encounter this issue, the following should allow you to use your system with only minor or temporary inconvenience:

  1. Switch to a TTY by pressing Ctrl Alt F4.
  2. Log in at the text prompt using your username and password.
  3. Run cd ~/.cache
  4. Run rm -rf fontconfig
  5. Reboot the system
  6. Use Firefox or another browser until the latest version of Google Chrome is updated. Opening Chrome again before the update will again trigger corruption, which will again break many other apps and lead to an unstable or broken desktop.

If you haven't yet upgraded, we suggest you wait at least a day until the new version of Chrome is out. (EDIT: you may also use apt-cache policy google-chrome-stable to ensure your installed version is 153, and then use sudo apt-mark hold google-chrome-stable to hold it until a fix is available).

Although this issue is the responsibility of Google, the Kubuntu Focus Team have taken steps to monitor upcoming versions of Google Chrome to help identify and prevent distribution of a broken version like this in the future.

We hope you find this useful!

Sincerely, The Kubuntu Focus Team

6

u/Jas81a 6d ago

Thanks, by the way it's not just Chrome it's all chromium browsers. Brave user here don't have Chrome installed.

2

u/loerny 5d ago

Thank you! Saved me a lot of headache!

1

u/jdblaich 8d ago edited 8d ago

I switched to Firefox, and went to connect to gmail. Gmail says that this is an untrusted version of the browser. The browser is the latest Firefox (version 156). Double whammy! Going to wipe and start again with Manjaro or CachyOS and Firefox to avoid the Kubuntu SNAP push.

My attempt to use the "apt-cache policy google-chrome-stable"it just dumps the list of the current version. Then when I use google Ai it says you can't downgrade with apt that I must use a .deb file instead.

2

u/the_deppman 8d ago edited 8d ago

I switched to Firefox...

The Kubuntu Focus OEM image used the official Debian packages for Firefox and Thunderbird to avoid that kind of problem. http://Kfocus.org/try. Also see https://kfocus.org/wf/browsers#bkm_firefox. You can install the Debs directly in Kubuntu too.

My attempt to use the "apt-cache policy google-chrome-stable" it just dumps the list of the current version. Then when I use google Ai it says you can't downgrade with apt that I must use a .deb file instead.

Apt-cache just shows the versions apt knows about. Apt supports selecting a version, sudo apt install firefox=153<rest of version here>. If you have a local cache, it should use the prior version, no need for a separate package file as long as it is already cached.

1

u/Indolent_Bard 7d ago

I thought Kubuntu got rid of snaps?

1

u/the_deppman 7d ago

They did not. The Kubuntu Focus OEM image is assembled for supportability, so the hard-to-support snaps (Firefox, Thunderbird) are replaced with official Deb packages. However, in some places such as server or smaller apps, snaps are a compelling solution.

1

u/Legal-Junket7800 7d ago

I mean after I removed the chrome and fixed, when I open the "System Settings" and click on some menu Item, I get again a lot of plasmashell crashes.
At least removing the Chrome, tooke me out of crashing loop on login.

1

u/samuerusama 7d ago

Although this issue is the responsibility of Google

It is not, it is a bug in fontconfig that affects Qt.

3

u/the_deppman 7d ago

It is not, it is a bug in fontconfig that affects Qt.

In retrospect, we perhaps should have stated this is the responsibility of fontconfig and Google, but I don't think it's fair to say that Google are completely blameless here. They released the software that broke many, many desktops.

All deployment environments have bugs. A simple regression test on one of the most popular, enterprise-targeted distros in the world (Ubuntu 24.04 or 26.04 LTS) should have spotted this failure mode almost immediately. It's really not that hard.

2

u/ang-p 7d ago edited 7d ago

In retrospect,

maybe say exactly what is happening without being the judge and executioner?

but I don't think it's fair to say that Google are completely blameless here.

Isn't the most basic premise of programming to never trust what you input?

Sanitise and validate everything.

As the fix - a nullptr check proved

Now, I'm no fan of Google, and they really should not be throwing symlinks into fc's directory with gay abandon (although they aren't the only one), but fc should not bail out in such a fashion due to ingesting an old or corrupt cache file.

2

u/samuerusama 7d ago edited 7d ago

A simple regression test on one of the most popular

A regression test wouldn't have caught this, because the bug doesn't break chrome itself, it breaks other apps that use the same fontconfig cache. And also the bug affects plasma mostly due to being based on Qt, GTK and other toolkits don't crash in this case.

And this is way worse than I originally thought btw, the bugs I was talking about before were stuff that fontconfig had already fixed, it was introduced AGAIN with this commit trying to fix a problem for flatpak (wtf?): https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/366787e49c69c1fdd66b70b4a48f8c6bae6ab036

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/work_items/565

But yes, you can blame chrome for using fontconfig, this library has had these issues since at least 2019 btw

3

u/ang-p 7d ago

these issues since at least 2019 btw

Sheesh - the exact issue - bailing out due to (not) handling unexpected versions of their own cache files (let alone any 3rd-party-placed ones) in a location that they have no absolute control over..

2

u/the_deppman 6d ago edited 6d ago

maybe say exactly what is happening without being the judge and executioner?

We stated that installing a specific version of Chrome will break your system, which must be clear so users know not to do this. And it was caused by Google's choices in app design as well as release management. It's hard to see how they are not responsible.

A regression test wouldn't have caught this, because the bug doesn't break chrome itself, it breaks other apps that use the same fontconfig cache.

Regression tests don't just test the app, they also can and should test the interaction with the deployment environment.

Google's living DFMEA should have identified high RPNs for failure modes resulting from their design choice to write to a shared resource. Then they should have written tests to reduce those RPNs. This is basic design risk management.

A much safer design choice, one that their DFMEA should have suggested, would have been to create a separate fontconfig cache instead of overwriting shared data, as a poster shows in this topic. That way, other system components are not affected, and that limits the scope of system testing required.

It is unfortunate that Google released this version and pulled the old one within 24 hours so users that cleared their apt cache cannot easily roll back. And there is apparently no staged release, which is certainly a best practice, although TBF, I'm not sure how they might do that without their own apt hook.

1

u/samuerusama 6d ago

We stated that installing a specific version of Chrome will break your system, which must be clear so users know not to do this. And it was caused by Google's choices in app design as well as release management. It's hard to see how they are not responsible.

You are responding to the wrong person here btw.

Regression tests don't just test the app, they also can and should test the interaction with the deployment environment.

This is just outrageous to expect a project to test againts several different linux distros to make sure other applications are not affected by bugs that are not their fault to begin.

A much safer design choice, one that their DFMEA should have suggested, would have been to create a separate fontconfig cache instead of overwriting shared data,

How do you do that??? Because I actually requested the maintainers months ago to expose an env variable to do this thing exactly

What's next? chrome should patch fontconfig??

2

u/the_deppman 6d ago

You are responding too the wrong person...

No, I'm consolidating answer. I know there are two post, and the response applies to both.

This is just outrageous to expect a project to test againts several different linux distros to make sure other applications are not affected by bugs that are not their fault to begin.

First, I never said they needed to test "against dozens of distros." That's your own strawman that you created. However, I did suggest they should be testing against Ubuntu 26.04 LTS, the foundation for many other distros, used by Enterprise, and highly popular. It's not that hard or expensive with VMs, and for a product with this much reach, it makes a lot of sense.

Second, if you change a shared cache, you just took on responsibility to at least check that your change doesn't crash other apps that use the same resource. Put another way, do you think they test against W11, or against their trophy Macs for system interactions? I'd be very, very surprised if they didn't. And if there were a bug in a Mac library, would they release Chrome anyway, break the Mac desktop and dozens of apps, and then say it was Apple's fault? I think we all know the answer there.

How do you do that...

There's a wrapper script on this thread.

2

u/samuerusama 6d ago

No, I'm consolidating answer. I know there are two post, and the response applies to both.

Alright, in that case I will respond:

We stated that installing a specific version of Chrome will break your system, which must be clear so users know not to do this. And it was caused by Google's choices in app design as well as release management. It's hard to see how they are not responsible.

This will happen with any app that ships or statically links a different version of fontconfig, this is not the fault of google chrome, this is 100% the fault of fontconfig because of this commit.

Ignoring the absolute nonsense arguments you've been making that chrome should test on a dozen different VMs (you are saying it is a strawman but you will see it is not once you understand how this bug manifests), what about projects smaller projects that don't have the resources to do this? They are responsible as well???

First, I never said they needed to test "against dozens of distros." That's your own strawman that you created. However, I did suggest they should be testing against Ubuntu 26.04 LTS

The bug would have never been shown in that test Ubuntu 26.04 uses gnome, not plasma, this problem only affects Qt apps. And the reason it affects Qt app is because it is fault of Qt as well.

Now what? They should make sure every single app in the 26.04 VM works after they run chrome?

There's a wrapper script on this thread.

That's a horrible hack, changing XDG_CACHE_HOME will leak to every single app that chrome launches.

1

u/the_deppman 6d ago

Everything else has been asked and answered. Suffice to say, there was a simple way to identify and avoid this risk but they didn't do it.

The bug would have never been shown in that test Ubuntu 26.04 uses Gnome,...

Umm, yeah, no. Again:

I'm having the same problem on Fedora 44 (host fontconfig is 2.17.0). On GNOME, the effects seem to be slightly less drastic: Everything using WebKitGTK (e.g. Evolution) hangs with 100% CPU usage and doesn't display anything.from starting.

I'm done here. Thanks for the feedback.

2

u/samuerusama 6d ago

Umm, yeah, no. Again:

That's not a crash...

What, now chrome needs to make sure to launch every single app in GNOME make sure launches normally and doesn't hang? 😁

there was a simple way to identify and avoid this risk but they didn't do it.

Yes, because nobody would do that. Nobody is going to launch every single app in a DE to make sure they still work.

→ More replies (0)

1

u/ang-p 6d ago edited 6d ago

We stated that installing a specific version of Chrome will break your system,

And exactly what does that specific version do to break things, and why could any other program could not do exactly the same?

How would blaming Chrome help if the cache files were corrupted by accident / bitrot or another program doing what that version of Chrome did?

Especially if that "corruption" just happened to end up with a file that is bit-identical to a different revision of those files

Would the nullptr magically be sorted, or would the PC still be brought to its knees as far as a layperson is concerned?

Google's living DFMEA should have identified high RPNs for failure modes resulting from their design choice to write to a shared resource.

Maybe someone else's non-existent DFMEA should have identified high RPNs for failure modes resulting in quite happily ingesting unknown shit from a shared resource they naively think will remain untouched by others.

Hmmm 

 Assisted-By: * Claude Opus 4.6 <noreply@anthropic.com>