https://bugs.kde.org/show_bug.cgi?id=492506
Anrich <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #32 from Anrich <[email protected]> --- Created attachment 195773 --> https://bugs.kde.org/attachment.cgi?id=195773&action=edit kwin_wayland 6.7.3 main-thread backtrace — TabBox::show() into non-terminating QQuickLayout rearrange This appears to have recurred on Plasma 6.7.3, on code that already carries the fix from comment 31 / kdeplasma-addons MR !663. Symptoms are identical to the original report: kwin_wayland pinned at 100% CPU on its main thread, no input, no repaints, no D-Bus, recoverable only by killing KWin. Switcher was "Sidebar" ([TabBox] LayoutName=sidebar). Versions: kwin 6.7.3 plasmashell 6.7.3 plasma-desktop 6.7.3-1 kdeplasma-addons 6.7.3-1 qt6-base 6.11.1-1 qt6-declarative 6.11.1-3 nvidia-utils 610.43.03-3 (proprietary), RTX 4080 Laptop Arch Linux, kernel 7.1.4-arch1-1, Wayland session What I measured while it was wedged: - Main thread (PID 2031) in state R with an empty WCHAN, 100% of one core: spinning in userspace, not blocked in the kernel. - busctl --user call org.kde.KWin /KWin org.kde.KWin supportInformation timed out. - org.freedesktop.ScreenSaver also timed out. - No processes in D state. Memory and IO PSI both 0, 45 GiB RAM free, no swap. - loginctl unlock-session / activate had no effect. Ctrl+Alt+F<n> VT switching did not work either, consistent with a wedged compositor holding DRM master. Earlier comments in this bug suspected the GPU or drm_commit_thread, so for what it is worth I can rule that out on my hardware: the kernel DRM log was clean for the entire boot (no Xid, no GPU reset, no page-flip timeout, nothing from nvidia_drm past driver load), nvidia-smi answered instantly showing 0% GPU utilization at 49 C with no throttling, and in the core the NVIDIA thread is sitting idle in pthread_cond_timedwait inside libnvidia-eglcore. The GPU was doing nothing at all. I SIGABRT'd the process to capture a core. Main thread backtrace, reading bottom-up: a QTimer fires, TabBox::show() runs, a QML binding updates, an expose event is delivered, polishItems() runs, and then the layout cycle never terminates: #4 qmlAttachedPropertiesObject(QObject*, QObject* (*)(QObject*), bool) libQt6Qml #5 ?? libQt6QuickLayouts #6 QGridLayoutItem::effectiveMaxSize(QSizeF const&) const libQt6Gui #7 QGridLayoutItem::geometryWithin(...) const libQt6Gui #8 QGridLayoutEngine::setGeometries(...) libQt6Gui #9 QQuickGridLayoutBase::rearrange(QSizeF const&) libQt6QuickLayouts #10 QQuickLayout::geometryChange(QRectF const&, QRectF const&) libQt6QuickLayouts #11 QQuickItem::setImplicitSize(double, double) libQt6Quick #12 QQuickLayout::ensureLayoutItemsUpdated(...) const libQt6QuickLayouts #13 QQuickLayout::updatePolish() libQt6QuickLayouts #14 QQuickWindowPrivate::polishItems() libQt6Quick ... #22 QWindowSystemInterface::handleExposeEvent<...>(QWindow*, QRegion const&) #26 QQmlBinding::doUpdate(...) #27 QQmlBinding::update(...) #28 QQmlNotifier::emitNotify(QQmlNotifierEndpoint*, void**) #30 KWin::TabBox::TabBox::show() libkwin #32 QTimer::timerEvent(QTimerEvent*) #36 QTimerInfoList::activateTimers() #40 QCoreApplication::exec() That is the same QQuickGridLayoutBase::rearrange / QQuickLayout::geometryChange cycle described in comment 28. Note the stack is shallow rather than deeply recursive, so this looks like a polish cycle that never converges rather than runaway recursion: the main thread simply never returns to the event loop. The reason I think this is a recurrence and not an unpatched system: MR !663 changed the delegate to height: delegateColumn.implicitHeight + 2 * delegateColumn.anchors.margins anchors { left: parent.left; top: parent.top; right: parent.right; margins: ... } replacing the old width: parent.width - 2 * Kirigami.Units.smallSpacing propagation. My installed /usr/share/kwin/tabbox/sidebar/contents/ui/main.qml from kdeplasma-addons 6.7.3-1 is character-for-character that post-fix version. So the freeze happened on patched code. One thing MR !663 did not touch, and my best guess at what is left, is the thumbnail placeholder in the same delegate: Item { Layout.fillWidth: true implicitHeight: Math.round(delegateColumn.width / tabBox.screenFactor) KWin.WindowThumbnail { anchors.fill: parent wId: windowId } } The child's implicitHeight is derived from the enclosing ColumnLayout's own width, that layout's implicit height is derived from the child, and the delegate's height is derived from the layout's implicitHeight. That closes a width -> implicit height -> delegate height -> ListView content height -> scrollbar -> width path which is not guaranteed to converge. It would fit the effectiveMaxSize / geometryWithin frames above, and it would also fit the external-display trigger reported in comment 22, since that is a width change. I want to be clear that this last part is a hypothesis from reading the QML against the trace, not something I confirmed: Arch's debuginfod carries no Qt6 debug packages, so I could not resolve the layout frames to line numbers or inspect locals. I also do not have a reliable reproducer. The trace shows the switcher being shown from its QTimer, so Alt+Tab, but I do not know what tips the layout into non-convergence: window count, a thumbnail still loading, or a width change. It had been running for about seven hours before it wedged. Happy to run anything specific if it helps. I still have the core dump (15 MB compressed) and can attach it, or pull anything out of it you want. Full 45-frame backtrace attached. Workaround for anyone landing here, no relogin needed: kwriteconfig6 --file kwinrc --group TabBox --key LayoutName compact qdbus6 org.kde.KWin /KWin reconfigure Could this be reopened? -- You are receiving this mail because: You are watching all bug changes.
