My file manager kept crashing. I blamed the cloud. I was wrong.
Monday evening, after all-day waiting on medical exams and remoting into my home machine with a tablet, Dolphin (my Linux file manager) crashed. Konsole crashes. Ark crashes. Even the SSH password prompt crashes. Every KDE app on my laptop segfaulted within minutes on a machine that had been rock solid for a week.
My first suspect was obvious: rclone. I have Google Drive and OneDrive mounted as FUSE filesystems, and the crashes seemed to happen while browsing them. So I spent hours on the mounts. Restarting them. Checking tokens. Reading journals.
Still crashing.
So I checked KWallet. Innocent.
Then the NVIDIA driver and the Wayland stack. Innocent.
Then a full font audit, and there it was: a “font file” in my fonts folder that turned out to be a GitHub 404 HTML page, saved with a .ttf name by a curl without -f. A corrupt file, right where the crash backtrace pointed (fontconfig). I removed it, rebuilt the caches, and the crashes stopped. Declared victory.
Then I rebooted. The crashes came back.
That reboot forced the real answer out. The backtrace was identical, but the crash was a use-after-free of cache data, not bad font data. And the fontconfig cache directory told the story: at login, someone had rewritten every cache file in a NEW format, format 12, with compatibility symlinks pointing the system’s format-9 readers at them.
The writer? Brave. It auto-updated to Chromium 154 that afternoon; the exact moment the storm began. Chromium 154 bundles its own, newer fontconfig, and on launch it writes its cache into the SHARED ~/.cache/fontconfig. My system fontconfig followed the symlink, accepted the file, and read a format-12 structure as format-9. Garbage in memory. SIGSEGV in every app that draws text. A known upstream regression, hours old, filed the same day.
Get Joao Silva’s stories in your inbox
Join Medium for free to get updates from this writer.
The fix is a one-liner: run the browser with a private XDG_CACHE_HOME so its caches stay out of the shared directory. Verified, documented, done.
Three lessons I’m keeping:
1. When many unrelated apps crash the same way, read the coredump backtrace before anything else. coredumpctl debug <app> named the guilty library before the timeline did.
2. “Fixed” isn’t fixed until you’ve survived a reboot and can explain the mechanism. My first fix worked by coincidence: it flushed the poisoned cache files without touching what wrote them.
3. Ask what writes to shared state. The bug wasn’t in rclone, the driver, or any component I was testing. It was in the interaction between two fontconfigs over one cache directory.
(And yes, the corrupt “font” was real, and it’s still gone. Use curl -fL and verify downloads with `file`. But it was a red herring, and red herrings that arrive with plausible evidence are the dangerous ones.)
I've written everything up as a gotcha in my machine rebuild repo, so future me never has to learn this twice.
And I am still waiting to be discharged from the hossy….
#Linux #KDE #Debugging #Chromium #OpenSource #Sysadmin #BuildInPublic
