https://bugs.kde.org/show_bug.cgi?id=527314
unleashit <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from unleashit <[email protected]> --- This one hit me too. Had an LLM try to diagnose, and try to replicate. Here's what it had to say: Second confirmation, with a deterministic trigger — I suspect the intermittency is the reason this is hard to catch. Fedora 44 KDE live image, Plasma 6.7.5, Qt 6.11.2, Kirigami 6.31.0, Wayland, single 3840x2160 display at 2x scale, LEFT edge. Repro via the shell's DBus scripting, no manual resizing, hangs 100% of attempts: 1. create a panel on the left edge (formFactor vertical) 2. addWidget("org.kde.plasma.windowlist") -> shell stays responsive 3. set panel thickness 120 -> still fine 4. set panel thickness 150 -> main thread never returns; every DBus call times out, one core pinned, RSS climbs, SIGTERM is ignored (systemd had to SIGABRT after 40s) Control: digitalclock in the same panel at the same thickness is fine, and removing Window List from the wide panel makes plasmashell responsive again within a second. Thickness boundary here: OK at <=120, hangs at >=150 -- i.e. matches the 144 px figure, and it is not edge- or scale-specific (right edge/scale 1 in the report, left edge/scale 2 here). Horizontal panels are unaffected at any length. With the wide panel saved in appletsrc, plasmashell hangs during startup before drawing any panel. Attached a symbolicated backtrace (identical in two samples 6s apart, all other threads idle). It reads as a re-entrancy loop rather than a colour problem: the widget's representation is reparented from inside setSize() during layout (PlasmaQuick::AppletQuickItemPrivate::compactRepresentationCheck -> QQuickItem::setParentItem -> QQuickItemPrivate::refWindow -> QQuickLabel::itemChange -> windowChanged -> Kirigami::PlatformTheme::update -> PlatformThemeChangeTracker destructor -> emitSignalsForChanges -> QQmlNotifier::emitNotify), and that re-enters polishItems -> QQuickGridLayoutBase::rearrange -> QGridLayoutEngine::setGeometries -> setSize, so each pass re-triggers the compact/full representation switch. That supports comment #6: changes=127 looks like the resize loop dragging the theme tracker along, not colorsChanged being the cause. Happy to re-capture with instrumentation in compactRepresentationCheck() if that narrows it down. -- You are receiving this mail because: You are watching all bug changes.
