Created attachment 164663 [details] gdb session with backtrace SUMMARY Most times I connect my laptop to a Dell WD22TB4 thunderbolt dock with 2 external screens (both 4K), kwin_wayland crashes. I can consistently reproduce the problem using the steps below and usually reproduce it if I connect the laptop to the dock some time after logging in. For context, this dock is at work. Before the break over the holidays, I had no issues with this set up and only started experiencing it after I came back to work. During this break, I upgraded the KDE Plasma stack from 5.27.9 to 5.27.10 (and related KDE framework dependencies) which is where I suspect the problem comes from. My normal screen set up with the dock connected is to have both monitors enabled at 125% scaling (side-by-side) and to disable the laptop screen. I have tried modifying this set up by enabling the laptop screen as well and setting the display scaling on the external screens to 100% but I still have the same problem. I have also tried disconnecting 1 screen. STEPS TO REPRODUCE 1. Turn on laptop with dock connected and external monitors to dock. 2. Log into my account from SDDM login screen. OBSERVED RESULT kwin_wayland crashes almost immediately and I am eventually left with black screens and a cursor. EXPECTED RESULT No crash. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 39 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.6.8-200.fc39.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × 12th Gen Intel® Core™ i7-1260P Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: Framework Product Name: Laptop (12th Gen Intel Core) System Version: A6 ADDITIONAL INFORMATION Please find a stack trace generated from the coredump using gdb attached. Please let me know if there is any further information I can provide to help debug this.
#5 0x00007f949ed2c8f7 in std::clamp<double> (__val=<optimized out>, __lo=<optimized out>, __hi=<optimized out>) at /usr/include/c++/13/bits/stl_algo.h:3667 #6 std::clamp<double> (__hi=<optimized out>, __lo=<optimized out>, __val=<optimized out>) at /usr/include/c++/13/bits/stl_algo.h:3667 #7 KWin::Window::constrainClientSize (this=0x557439a27200, size=<optimized out>, mode=<optimized out>) at /usr/src/debug/kwin-5.27.10-1.fc39.x86_64/src/window.cpp:4278 #8 0x00007f949ed2e578 in KWin::Window::constrainFrameSize (this=this@entry=0x557439a27200, size=..., mode=mode@entry=KWin::Window::SizeModeAny) at /usr/src/debug/kwin-5.27.10-1.fc39.x86_64/src/window.cpp:4290 #9 0x00007f949ed350e9 in KWin::Window::checkWorkspacePosition (this=<optimized out>, oldGeometry=..., oldDesktop=<optimized out>) at /usr/src/debug/kwin-5.27.10-1.fc39.x86_64/src/window.cpp:4236 #10 0x00007f949ed57c24 in KWin::Workspace::updateClientArea (this=this@entry=0x5574388fba90) at /usr/src/debug/kwin-5.27.10-1.fc39.x86_64/src/workspace.cpp:2441
It's an assert, presumably min > max or vice versa. Miren this probably means you have some window rules set somewhere that might be causing this.
(In reply to David Edmundson from comment #2) > It's an assert, presumably min > max or vice versa. > > Miren this probably means you have some window rules set somewhere that > might be causing this. I don't have any Window Rules under System Settings -> Window Management -> Window Rules and I don't remember setting any elsewhere. Anywhere else I should check? I tried disabling some non-default KWin scripts (specifically "Sticky Window Snapping" and "Ultrawide Windows") but that didn't seem to help either.
The maintainers may find this useful: I can also reproduce this crash without an external monitor. STEPS TO REPRODUCE 1. Install application Nekoray: https://github.com/MatsuriDayo/nekoray/releases; 2. Add it to Auto Start list in KDE Settings; 3. Ensure that both X11 and Wayland sessions are installed and enabled; ensure that "auto restoring applications running at last logout" is also enabled; 4. Switch to X11 session, so that Nekoray launches at login; 5. Log out and switch back to Wayland session from SDDM; 6. Nekoray starts (by auto session recovery), starts again (by auto start) and crashes kwin_wayland. kwin_wayland can restart itself properly, but does not bring up autostart applications and user services again. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 Kernel Version: 6.6.9-x64v2-xanmod1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO ADDITIONAL INFORMATION The stack trace is similar to the posted one. Crashed in std::clamp<double>. I have no window rules listed in Window Rules either.
*** This bug has been marked as a duplicate of bug 478269 ***
(In reply to Zamundaaa from comment #5) > > *** This bug has been marked as a duplicate of bug 478269 *** Are we sure this is a duplicate of bug 478269? Whilst I agree that the tops of the stack traces look the same (#0-#10), they look a bit different further down the stack and I think the fix for bug 478269 may have been made where they differ. The fixes for bug 478269 seem to be in wayland/xdgshell and xdgshellwindow. Code from these components is in the stack trace for bug 478269: #15 0x00007f06087468fd in KWin::XdgSurfaceWindow::handleNextWindowGeometry() (this=0x55afdb3e04f0) at /usr/src/debug/kwin/kwin-5.27.10/src/xdgshellwindow.cpp:242 boundingGeometry = {xp = 0, yp = 0, w = 58, h = 27} frameGeometry = {xp = 0, yp = 0, w = 58, h = 27} #16 KWin::XdgSurfaceWindow::handleCommit() (this=0x55afdb3e04f0) at /usr/src/debug/kwin/kwin-5.27.10/src/xdgshellwindow.cpp:169 However, I don't see anything from these components in my stack trace for this bug. Sorry if I'm being completely naive about this as I'm not too familiar with KDE development. I just really want to make sure the fix for this bug is released asap as it's really inconvenient.
In the other bug report the check is being by a surface commit, here it's triggered by output changes, but both should have the same cause. *** This bug has been marked as a duplicate of bug 478269 ***