Same symptom here on a second 24.04-based system (Zorin OS 18.1, X11, Intel
Sandy Bridge, so not NVIDIA-specific):
evolution 3.52.3-0ubuntu1.1
libwebkit2gtk-4.1-0 2.52.6-0ubuntu0.24.04.1
fontconfig 2.15.0-1.1ubuntu2
google-chrome-stable 154.0.8037.57-1 (Google's deb repo)
Root cause, and why rebuilding the user cache fixes it
-------------------------------------------------------
This is not a WebKitGTK regression by itself. Google Chrome 154 bundles
fontconfig 2.18.3, which on first launch after the upgrade wrote 51 files
named *-le64.cache-12 into ~/.cache/fontconfig (one per font directory) and,
for each of them, symlinks named *-le64.cache-9, cache-10 and cache-11
pointing at the cache-12 file. That is a 2.18.3 feature ("fc-cache: Create
backward-compatible cache symlinks for cross-version discovery" in NEWS).
The system fontconfig 2.15 opens <hash>-le64.cache-9, follows the symlink,
and accepts the format-12 file because FcDirCacheMapFd only rejects caches
with version < FC_CACHE_VERSION_NUMBER. It also prefers it over the valid
system caches in /var/cache/fontconfig because it is newer. fontconfig
2.18.3 additionally records WOFF/WOFF2 files as placeholder patterns with no
family ("Add woff wrapper and filename if file is woff or woff2"); here those
come from fonts-opendyslexic in /usr/share/fonts/woff. WebKit's
SkFontMgr_fontconfig GetFamilyNames() then loops forever on a pattern with no
family, which is the 100% CPU main thread in the backtrace above. fc-list and
fc-match still work, GTK apps still work, only WebKit hangs.
Evidence on this machine: the cache-12 files and symlinks were written at
10:29:30-10:29:36, Chrome was launched at 10:29:29 (journal), and Evolution
broke on its next start. A standalone 20-line WebKitGTK 2.52.6 test view
hangs the same way with sandbox on or off and with software GL, and loads
instantly when XDG_CACHE_HOME points at a fresh directory.
Related reports
---------------
fontconfig (Ubuntu) bug 2168420 - same cache, crashes Qt6/KDE in
FcCharSetHasChar instead of looping; names Chrome 154 / fontconfig 2.18.3
https://bugs.webkit.org/show_bug.cgi?id=325185 - the WebKit loop, with a
proposed patch
https://github.com/brave/brave-browser/issues/59349 and
https://github.com/openai/codex/issues/48217 - other Chromium 154 apps
Reported upstream to Chromium as issue 565132857
fontconfig upstream: gitlab.freedesktop.org/fontconfig/fontconfig work item
565
Workaround that survives Chrome relaunches
------------------------------------------
evolution --force-shutdown
pkill -x WebKitWebProces
find ~/.cache/fontconfig -type l -delete
fc-cache -f
Deleting only the symlinks and leaving Chrome's cache-12 files in place
matters: Chrome then finds its own caches valid and does not rewrite them.
"rm -rf ~/.cache/fontconfig" also works but Chrome regenerates everything,
symlinks included, on its next launch. Note the symlink code in
FcDirCacheWrite() does unlink() before symlink(), so the next time Chrome
rewrites a directory's cache (e.g. after a font package update changes a
directory mtime) the real cache-9 files will be replaced again. As of today
Google's repo still serves 154.0.8037.57-1, so no fixed Chrome is available.
Suggest marking this as also affecting fontconfig and linking bug
2168420.
** Bug watch added: bugs.webkit.org/ #325185
https://bugs.webkit.org/show_bug.cgi?id=325185
** Bug watch added: github.com/brave/brave-browser/issues #59349
https://github.com/brave/brave-browser/issues/59349
** Bug watch added: github.com/openai/codex/issues #48217
https://github.com/openai/codex/issues/48217
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2168520
Title:
Evolution WebKitWebProcess enters persistent 100% CPU loop in
fontconfig; rebuilding user fontconfig cache fixes it
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/2168520/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
