Follow-up: root cause appears to be cross-version fontconfig cache incompatibility triggered by Chrome 154
The issue has now reproduced again on my Ubuntu 24.04.4 system after the initial fontconfig cache rebuild, and a second independent reporter has reproduced the same symptom on another Ubuntu 24.04-based system (Zorin OS 18.1, X11, Intel Sandy Bridge). This confirms that the issue is not NVIDIA-specific. On my system, the recurrence again produced multiple Evolution-owned WebKitWebProcess instances at ~100% CPU each. A second GDB backtrace again showed the same hot main-thread path: libfontconfig.so.1 -> FcPatternGetString() -> libwebkit2gtk-4.1.so.0 while the other threads were blocked normally in poll()/GLib main loops. I also performed an A/B test with the OpenDyslexic WOFF fonts: With the WOFF files present in: /usr/share/fonts/woff/opendyslexic/ fontconfig produced clearly abnormal matches, e.g.: fc-match sans-serif -> OpenDyslexic-Bold.woff while reporting family "Noto Sans" fc-match serif -> OpenDyslexic-Bold.woff while reporting family "Noto Serif" fc-match monospace -> OpenDyslexic-Bold.woff while reporting family "DejaVu LGC Sans Mono" After temporarily moving only the four OpenDyslexic WOFF files out of the font path and rebuilding the font cache: fc-match sans-serif -> NotoSans-Regular.ttf fc-match serif -> NotoSerif-Regular.ttf fc-match monospace -> DejaVuSansMono.ttf Evolution/WebKit then returned to normal CPU usage. This initially made the WOFF fonts look like the root cause, but the newer independent analysis suggests they are only the trigger exposed by a cross-version fontconfig cache problem. The stronger root-cause explanation is now: 1. Google Chrome 154 bundles fontconfig 2.18.3. 2. That version writes cache-12 files into ~/.cache/fontconfig and creates backward-compatibility symlinks cache-9/cache-10/cache-11 -> cache-12. 3. Ubuntu 24.04 system fontconfig 2.15 follows those symlinks and accepts the newer cache-12 files. 4. The newer cache format can contain WOFF/WOFF2 placeholder patterns without a family. 5. WebKit's fontconfig-based family enumeration then gets stuck on such a pattern and spins indefinitely in the main thread. This also explains why: rm -rf ~/.cache/fontconfig or rebuilding the cache only fixes the problem temporarily: Chrome later regenerates the cache-12 files and compatibility symlinks. A workaround reported to survive Chrome relaunches is: evolution --force-shutdown pkill -x WebKitWebProces find ~/.cache/fontconfig -type l -delete fc-cache -f The important detail is to delete only the compatibility symlinks, while keeping Chrome's cache-12 files. Then Chrome considers its own caches valid and does not immediately regenerate the symlinks. Related Ubuntu bug: https://bugs.launchpad.net/bugs/2168420 That bug describes the same cross-version fontconfig cache layout causing crashes in Qt6/KDE applications instead of a WebKit CPU loop. Related upstream reports: https://bugs.webkit.org/show_bug.cgi?id=325185 https://github.com/brave/brave-browser/issues/59349 https://github.com/openai/codex/issues/48217 Please consider marking this bug as also affecting the Ubuntu fontconfig package and linking it to bug 2168420. I can also attach the second GDB backtrace from the recurrence if useful. -- 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
