https://bugs.kde.org/show_bug.cgi?id=524701
Bug ID: 524701
Summary: plasmashell reproducibly hangs (infinite recursion,
not a crash) with 95-190% CPU pinned on one thread and
D-Bus completely unresponsive, first seen 2026-08-23
and recurring since (most recently 2026-08-24).
kwin_wayland remains healthy throughout — this
Classification: Plasma
Product: plasmashell
Version First master
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
## Summary
plasmashell reproducibly hangs (infinite recursion, not a crash) with 95-190%
CPU pinned on one thread and D-Bus completely unresponsive, first seen
2026-08-23 and recurring since (most recently 2026-08-24). kwin_wayland remains
healthy throughout — this is isolated to the plasmashell process.
## Environment
- TUXEDO OS (Debian testing/"forky" base), package manager apt
- KDE Plasma 6, Wayland session (plasmashell + kwin_wayland)
- Hybrid graphics: AMD HawkPoint iGPU + NVIDIA RTX 4070 Max-Q
(nvidia-open-kernel-dkms 580.178.04)
- Package versions at time of investigation:
libkirigami*/qml6-module-org-kde-kirigami* 6.28.0-1, qt6-base/qt6-declarative
6.10.2, plasma-desktoptheme 6.7.4-2
## Confirmed backtrace (gdb -p <pid> -batch -ex "thread apply all bt", no
elevated privileges needed)
Repeated `QQuickItemPrivate::refWindow(QQuickWindow*)` frames, entered via
`KirigamiPlasmaStyle.so`'s reaction to a `QQuickPage`/`Pane`/`Label`'s
`setParentItem()`. A later sample of the same hung process instead caught
`QObjectPrivate::deleteChildren()` blocked on a mutex — consistent with the
same pathologically deep object graph now being torn down, not a second bug.
## Steps to reproduce
Not fully deterministic, but reproduces reliably on this machine across:
- A completely blank/default Plasma panel config
(`~/.config/plasma-org.kde.plasma.desktop-appletsrc` set aside) — rules out
user widget/panel configuration as the cause.
- A cold boot (not just post-suspend/resume) — rules out session-resume state
as the cause.
- Both the `org.kde.breezedark.desktop` and `org.kde.breeze.desktop`
Look-and-Feel themes — rules out that specific theme being the trigger.
## What has been ruled out
1. Third-party Plasmoid ("Panel Spacer (Extended)",
`luisbocanegra.panelspacer.extended`) — removed entirely, hang still
reproduced.
2. Broken output/display config — `kscreen-doctor -o` clean throughout.
3. Qt6/Kirigami package version mismatch — internally consistent, nothing
upgradable.
4. Forcing the alternate `org.kde.desktop` QtQuickControls style via
`QT_QUICK_CONTROLS_STYLE` — Kirigami force-loads `KirigamiPlasmaStyle` under a
real Plasma session regardless.
5. Fresh session (full logout/reboot) — hang recurs on a session only ~3
minutes old.
6. Blank/default panel config — hang recurs with a stock config.
7. Forcing the single-threaded Qt Quick render loop (`QSG_RENDER_LOOP=basic`) —
hang still reproduced.
8. Look-and-Feel theme switch (breezedark -> breeze) — appeared to fix it once,
but the hang recurred later on the "fixed" theme too, so theme is not the
trigger.
## Workaround
`systemctl --user restart plasma-plasmashell.service` reliably restores
plasmashell to a working state within seconds (confirmed multiple times: CPU
drops from >120% pinned to ~15-20%, D-Bus responds again, a live
`evaluateScript` query against `/PlasmaShell` returns correct panel data). This
is a mitigation only, not a fix — the hang recurs unpredictably afterward.
## Possibly related (not confirmed as duplicate)
An Arch Linux forum thread
(https://bbs.archlinux.org/viewtopic.php?pid=2304981#p2304981) describes a
strikingly similar mechanism — a crash originating in
`Kirigami::Platform::PlatformTheme::setTextColor()` (libKirigamiPlatform.so.6)
that recurses through `QQuickItemPrivate::refWindow()` after
`QQuickItem::setParentItem()`, on plasmashell 6.7.3 under Wayland (Hyprland
compositor in that case). That report was a hard crash/segfault rather than a
hang, and no KDE Bugzilla report was ever filed for it, but the code path
(Kirigami style plugin reacting to a reparent and recursing into refWindow)
matches closely enough that it may be the same underlying defect surfacing
differently depending on compositor/timing.
--
You are receiving this mail because:
You are watching all bug changes.
