Public bug reported:
Ubuntu release
==============
Ubuntu 24.04.4 LTS
Desktop environment
===================
MATE / X11
Affected application
====================
Evolution:
3.52.3-0ubuntu1.1
Evolution Data Server:
3.52.3-0ubuntu1.2
Affected WebKitGTK versions tested
==================================
libwebkit2gtk-4.1-0:
2.52.6-0ubuntu0.24.04.1
For diagnostic purposes I also downgraded and tested:
2.52.3-0ubuntu0.24.04.1
The problem occurred with both versions.
Graphics hardware
=================
NVIDIA GeForce RTX 3080 Ti
proprietary NVIDIA driver
X11 session
Summary
=======
Evolution became effectively unusable because an Evolution-owned
WebKitWebProcess continuously consumed approximately 99-100% CPU.
The problem occurred immediately after starting Evolution. It did not
require manually starting Send/Receive and it also occurred with the
message preview disabled.
Evolution itself consumed only a few percent CPU. The CPU load was in
WebKitWebProcess.
The WebKit process was confirmed by pstree to be a child of Evolution
through the normal bubblewrap sandbox:
evolution
-> bwrap
-> bwrap
-> WebKitWebProcess
The issue was eventually traced to the fontconfig/font matching path.
A GDB backtrace of the CPU-consuming WebKit main thread showed:
#0 __strcmp_avx2()
#1 ... from libfontconfig.so.1
#2 FcPatternGetString()
#3 ... from libwebkit2gtk-4.1.so.0
#4 ... from libwebkit2gtk-4.1.so.0
...
The other WebKit threads were mostly blocked normally in poll(),
g_cond_wait(), or WTF::RunLoop::run().
Rebuilding the user's fontconfig cache completely resolved the issue.
After rebuilding the fontconfig cache:
- WebKitWebProcess CPU usage dropped from approximately 100% to below 1%
when idle.
- Evolution remained responsive.
- Send/Receive worked normally.
- Evolution terminated normally.
- The issue remained fixed after returning WebKitGTK from the diagnostic
downgrade to the current Ubuntu version 2.52.6-0ubuntu0.24.04.1.
Impact
======
The user-visible effect was severe:
- One WebKitWebProcess continuously used almost one full CPU core.
- At times more than one WebKitWebProcess entered this condition.
- Evolution could no longer be closed normally.
- Evolution displayed multiple apparently unfinished processing tasks.
- The computer ran at high load.
- The symptoms initially looked like a mail retrieval, IMAP, Evolution
database, or HTML email problem.
For a normal desktop user the actual cause is practically impossible to
identify.
Reinstalling Evolution would also not necessarily fix the problem,
because the problematic state was outside the Evolution package itself
and was resolved by rebuilding the user's fontconfig cache.
Reproduction and investigation
==============================
The following tests were performed.
1. Evolution was force-stopped and restarted.
Result:
WebKitWebProcess again reached approximately 100% CPU.
2. Evolution was started without manually selecting Send/Receive.
Result:
The problem occurred anyway.
Therefore mail retrieval itself was not required to trigger the issue.
3. Evolution message preview was disabled before Send/Receive.
Result:
WebKitWebProcess still reached approximately 100% CPU.
Therefore displaying a selected HTML message was not required.
4. Evolution's WebKit cache was moved away so that it could be
recreated.
The cache directory involved was:
~/.cache/evolution/WebKitCache
Result:
No improvement.
5. Evolution configuration was temporarily replaced with a fresh
configuration by moving:
~/.config/evolution
out of the way.
Evolution was started without configuring mail accounts.
Result:
WebKitWebProcess still immediately reached approximately 100% CPU.
Therefore the problem was not caused by the existing Evolution profile.
6. WebKit compositing was disabled:
WEBKIT_DISABLE_COMPOSITING_MODE=1 evolution
Result:
No improvement.
7. DMA-BUF rendering was disabled:
WEBKIT_DISABLE_DMABUF_RENDERER=1 evolution
Result:
No improvement.
8. Software OpenGL rendering was forced:
WEBKIT_DISABLE_DMABUF_RENDERER=1
LIBGL_ALWAYS_SOFTWARE=1
evolution
Result:
No improvement.
This made the NVIDIA/OpenGL rendering path unlikely to be the cause.
9. WebKitGTK was downgraded as a controlled A/B test from:
2.52.6-0ubuntu0.24.04.1
to:
2.52.3-0ubuntu0.24.04.1
The matching packages were downgraded together:
- libwebkit2gtk-4.1-0
- libjavascriptcoregtk-4.1-0
- gir1.2-webkit2-4.1
- gir1.2-javascriptcoregtk-4.1
Result:
The problem remained.
Therefore the issue was not specific to WebKitGTK 2.52.6.
The system has subsequently been restored to 2.52.6.
strace result
=============
strace was attached to the CPU-consuming WebKitWebProcess.
The auxiliary threads were mainly waiting in calls such as:
poll()
read()
futex()
restart_syscall()
The CPU-consuming activity therefore appeared to take place in userspace
rather than being caused by a repeated network, filesystem, IMAP, or
other kernel I/O loop.
GDB result
==========
A GDB backtrace was captured from the affected WebKitWebProcess.
The main thread was located at:
#0 __strcmp_avx2()
#1 ... in libfontconfig.so.1
#2 FcPatternGetString()
#3 ... in libwebkit2gtk-4.1.so.0
#4 ... in libwebkit2gtk-4.1.so.0
...
The remaining threads were largely idle/waiting.
This was the first clear indication that the infinite/high-CPU loop was
related to WebKitGTK's fontconfig/font matching path rather than mail
retrieval or graphics rendering.
The complete GDB backtrace is available as an attachment.
Workaround / successful repair
==============================
Evolution was stopped.
The existing user fontconfig cache was moved out of the active cache
directory and the font cache was rebuilt.
Equivalent commands are:
rm -rf ~/.cache/fontconfig/*
fc-cache -f -v
For safety during the investigation I actually moved the existing cache
aside before recreating it.
After rebuilding the cache, Evolution was started again.
Result:
Before:
WebKitWebProcess approximately 99-100% CPU indefinitely.
After:
WebKitWebProcess approximately 0-1% CPU when idle.
Evolution then successfully performed Send/Receive without entering the
CPU loop.
WebKitGTK was subsequently updated/restored to the current Ubuntu
2.52.6 package and Evolution continued to work normally.
Additional fontconfig observation
=================================
During:
fc-cache -f -v
fontconfig printed several messages equivalent to:
"skipping, looped directory detected"
for standard font directories, including locations under:
/usr/share/fonts/truetype/
The filesystem was subsequently checked for recursive symlink loops.
The command:
find -L /usr/share/fonts -maxdepth 4 -type l -ls
did not identify a recursive filesystem symlink loop.
The symbolic links found under /usr/share/fonts were ordinary font aliases
and links to standard font/cmap locations.
Therefore the "looped directory detected" output should not be taken as
evidence that /usr/share/fonts contains an actual recursive filesystem
symlink loop.
Expected behaviour
==================
A stale, inconsistent or corrupted regenerable fontconfig cache should
not cause an Evolution-owned WebKitWebProcess to spin indefinitely at
approximately 100% CPU.
At minimum, the affected component should:
- detect a non-progressing font lookup,
- abort the lookup safely,
- emit a useful diagnostic message,
- or recover from the bad cache state.
Ideally, if a fontconfig cache is found to be inconsistent and can safely
be regenerated, the affected desktop component should either rebuild it
automatically or offer the user a recovery action.
Robustness / self-recovery suggestion
=====================================
Please consider whether the WebKitGTK/fontconfig interaction could be
made more robust in one or more of the following ways:
1. Validate fontconfig cache entries before using them in repeated font
matching operations.
2. Detect repeated/non-progressing fontconfig lookups.
3. Break out of the lookup instead of allowing the WebKit main thread to
consume a full CPU core indefinitely.
4. Fall back to a safe/default font if font matching cannot make
progress.
5. Emit a diagnostic warning that clearly identifies fontconfig or its
cache as the source of the problem.
6. Where technically safe, invalidate and regenerate the affected user
fontconfig cache.
7. Evolution/WebKitGTK could potentially detect that a WebKit process is
consuming sustained CPU without making progress and offer a recovery
option.
Why this matters for normal desktop users
=========================================
This issue is extremely difficult to diagnose without expert tools.
The visible symptoms suggest:
- an IMAP/mail synchronization problem,
- a damaged Evolution profile,
- a bad HTML message,
- a WebKit cache problem,
- a graphics driver problem,
- or a broken Evolution installation.
None of those turned out to be the actual cause.
The successful repair was only:
rebuild the fontconfig cache.
However, determining that this was the correct action required:
- process inspection,
- pstree,
- multiple controlled startup tests,
- disabling message preview,
- replacing the Evolution configuration,
- replacing the WebKit cache,
- disabling WebKit compositing,
- disabling DMA-BUF,
- forcing software rendering,
- testing two WebKitGTK versions,
- strace,
- and finally a GDB backtrace.
A normal user would very likely reinstall Evolution or possibly even the
operating system before discovering this cause.
It would therefore be valuable if this failure mode could either be
prevented, diagnosed automatically, or recovered from automatically.
Attachments
===========
1. Full GDB backtrace from the affected WebKitWebProcess:
evolution-webkit-gdb.txt
Additional diagnostic information collected automatically by ubuntu-bug
should also be attached to this report.
** Affects: webkit2gtk (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "evolution-webkit-gdb.txt"
https://bugs.launchpad.net/bugs/2168520/+attachment/6002520/+files/evolution-webkit-gdb.txt
--
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
