https://bugs.kde.org/show_bug.cgi?id=517684
--- Comment #3 from Giacomo <[email protected]> --- Created attachment 193718 --> https://bugs.kde.org/attachment.cgi?id=193718&action=edit plasma shell log Additional data point from FreeBSD + NVIDIA — this reproduces as a KWin DEADLOCK, with NO SIGSEGV (and no signal at all) on the monitor power-ON transition. I can reproduce the "freeze on monitor power cycle" reliably, but in my case there is *no crash signal whatsoever* — neither plasmashell nor kwin_wayland receives SIGSEGV/SIGABRT. The compositor hard-deadlocks instead. Given the bug title ("plasmashell SIGSEGV on monitor power cycle"), it may be worth checking whether the plasmashell SIGSEGV is a *secondary* effect (client dying against a wedged compositor) and the actual root cause is a KWin DRM-backend deadlock on the hot-plug/output-commit path. == How I captured it == gdb was attached to BOTH kwin_wayland and plasmashell *before* the test, each with catchpoints on SIGSEGV/SIGABRT/SIGBUS/SIGILL/SIGFPE/SIGSYS. During the monitor off→on cycle that froze the machine, **none of those catchpoints fired**. A 1 Hz procstat(1) kernel-stack sampler and live gdb backtraces were taken at the moment of the freeze. (The only core on the system was a self-inflicted `plasmashell --version` SIGABRT from QPA init during setup — unrelated.) == Environment == - FreeBSD 15.0-RELEASE-p4, amd64; Intel Core Ultra 9 285; 64 GB - GPU: NVIDIA RTX A400 (GA107GL) - nvidia-driver 595.80, nvidia-drm-66-kmod, nvidia-modeset 595.80, modeset=1 - KWin / Plasma 6.6.5, KDE Frameworks 6.26.0, Qt 6.11.1 - Wayland session, DRM backend, connector DP-2, Xwayland rootless == Trigger == Monitor OFF is clean (all kwin threads idle, no per-output thread exists). Monitor ON generates a DRM/udev hot-plug; kwin spawns the per-output commit thread named after the connector ("DP-2"), which immediately wedges. Screen freezes, input dead, hard reboot required. No NVIDIA Xid / GPU fault / DRM error in dmesg — the kernel GPU driver is healthy; this is a userspace deadlock in KWin. == The deadlock (live gdb, all-thread backtraces) == kwin_wayland — per-output commit/present worker thread "DP-2" (blocked forever): #0 _umtx_op_err #3 std::condition_variable::wait(unique_lock<mutex>&) libc++ #4 libkwin.so.6 (+0x7b465a) <-- DRM output worker #5 libkwin.so.6 (+0x7b4f42) <-- DRM output worker #6 std::__assoc_sub_state::copy() libc++ #7 std::future<void>::get() libc++ #8 libQt6Core (QThread entry) (The two libkwin frames sit between exported symbols KWin::DrmBackend::qt_metacall @0x7a4f20 and KWin::DrmConnector::refreshRateForMode @0x7b7410. No debuginfo package exists for plasma6-kwin on FreeBSD, so these locals could not be fully symbolized.) kwin_wayland — main/compositor thread (the other half of the deadlock): #0 _read #2 udev_monitor_receive_device libudev #3 KWin::UdevMonitor::getDevice() libkwin.so.6 #4 KWin::DrmBackend::handleUdevEvent() libkwin.so.6 #5 QSocketNotifier activation ... QCoreApplication::exec() So: the "DP-2" output worker is parked in std::future<void>::get() waiting on a promise, while the main thread is stuck servicing the monitor-power-on udev event in DrmBackend::handleUdevEvent() and never returns to fulfill it. They wait on each other -> deadlock -> all Wayland clients (plasmashell, Xwayland) block on the dead compositor. plasmashell at the freeze is just a victim: all of its threads are idle in poll()/ppoll() blocked on the frozen compositor. (Before settling, its QtQuick render thread briefly thrashed — rapidly creating/destroying threads — retrying against the unresponsive Wayland connection; on other setups that retry storm could plausibly be where a plasmashell-side SIGSEGV manifests.) == Question for the maintainers == Could the reported plasmashell SIGSEGV be downstream of this KWin hot-plug/output-commit deadlock (or of KWin tearing down/restarting under it)? On this hardware the root event is clearly a KWin DRM-backend deadlock with no signal. A debug-enabled KWin build would pinpoint the exact future/promise and the lock held by the main thread in DrmBackend::handleUdevEvent(); I'm happy to provide the cores (kwin 258 MB, plasmashell 434 MB), the full all-thread backtraces, the procstat kernel-stack timeline, and session/dmesg logs. -- You are receiving this mail because: You are watching all bug changes.
