https://bugs.kde.org/show_bug.cgi?id=526746
Bug ID: 526746
Summary: DrKonqi crashes recursively when it cannot connect to
X display, creating thousands of coredumps
Classification: Applications
Product: drkonqi
Version First 6.6.6
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
After upgrading my system from Kubuntu 24.04.5 to Kubuntu 26.04.1, I noticed
unusually high CPU usage, temperatures and fan activity when using my Plasma
desktop via XRDP.
During investigation I found that drkonqi-coredump-launcher had entered a
recursive crash loop.
The relevant error was:
qt.qpa.xcb: could not connect to display
followed by a failure to initialize the Qt xcb platform plugin.
drkonqi-coredump-launcher then terminated with SIGABRT and systemd-coredump
recorded its crash.
This appears to have caused DrKonqi to handle the crash of
drkonqi-coredump-launcher itself. The newly started drkonqi-coredump-launcher
failed in the same way, producing another coredump and causing the cycle to
repeat.
The scale of the loop was very large. For the affected boot ID
9f12dbbd517b478d9cbd21fd6ba287a5
I counted systemd-coredump entries using the structured journal fields.
There were 38,764 coredump entries ("dumped core") during that boot.
38,763 of these were for:
/usr/lib/x86_64-linux-gnu/libexec/drkonqi-coredump-launcher
At a later point, /var/lib/systemd/coredump contained 5,435 drkonqi coredump
files occupying approximately 4.1 GB.
The problem also survived the original boot. On subsequent Plasma sessions,
drkonqi-coredump-pickup.service processed old crashes using:
/usr/lib/x86_64-linux-gnu/libexec/drkonqi-coredump-processor --settle-first
--pickup --uid 1000
Old drkonqi-coredump-launcher crashes were picked up repeatedly. One example
was PID 700436. coredumpctl still contained its metadata while the
corresponding coredump storage file was reported as "(missing)".
After removing the old coredump files and rotating/vacuuming the old persistent
systemd journal, the problem disappeared.
After a reboot and a new XRDP/Plasma login, drkonqi-coredump-pickup.service
behaves normally:
Memory: 2.5M (peak: 3M)
CPU: 15ms
There are currently 0 files in /var/lib/systemd/coredump, and the excessive CPU
load and temperature problem has not returned.
System information:
Kubuntu 26.04.1 LTS (upgraded from Kubuntu 24.04.5)
KDE Plasma: 6.6.6
KDE Frameworks: 6.24
Qt: 6.10.2
DrKonqi package: 6.6.6-0ubuntu0.1
Kernel: 7.0.0-38
Session: X11 via XRDP
CPU: AMD Ryzen 7 5825U
libxcb-cursor0 is installed. ldd on Qt's libqxcb.so showed no missing
libraries. The XRDP X11 session is currently operating normally.
Expected behavior:
If drkonqi-coredump-launcher itself crashes while trying to handle a crash,
this should not result in an effectively recursive crash-reporting loop. There
should be a recursion guard, rate limit, or another mechanism preventing a
DrKonqi crash from repeatedly invoking DrKonqi again.
A failure to connect to the graphical display should at most make crash
reporting fail; it should not generate tens of thousands of additional crashes.
It may also be worth checking whether the pickup mechanism should repeatedly
attempt to process old DrKonqi crashes whose referenced coredump files no
longer exist.
Note:
I am not an IT professional. I investigated this problem interactively with the
assistance of OpenAI ChatGPT (GPT-5.6 Sol). ChatGPT guided the diagnostic
commands and helped analyze and correlate the systemd journal, coredumpctl
output, DrKonqi services and the recursive crash pattern. I executed the
commands on the affected machine, supplied the resulting output, and verified
the behavior before and after cleanup.
--
You are receiving this mail because:
You are watching all bug changes.
