Every few days plasma freezes while I am moving windows around. It's not a crash -- it doesn't seem to know it's frozen. So I can't do a backtrace. It's most often a konsole window that freezes everything, and gets stuck at the top of the screen. The system goes on working the cursor is stuck in the hand-grab window moving shape and can move around, but all user input except for the console hotkeys is ignored. There is no sign in dmesg or /var/log/messages that anything has happened. I can hotkey to a console window where kwin_x11 is hogging all of one cpu. Only workaround is to kill every thing with kill -9 and restart. I have all screen edge actions turned off, and touchpad actions. And still, just random freezes every few days. I wish I had more information. *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
You saw it happening on X session right? What GPU do you have? Because there's a similar one reported for Wayland here: https://bugs.kde.org/show_bug.cgi?id=499913 And I created a bug report too about Plasma freezing, which I can reproduce with the help of "Fall Apart" effect on USB drive and the "Wobbly windows" effect on internal SSD, but I really cannot figure out how to make the damn Kwin just write to a log file that I can find afterwards. I spent half a day trying to follow that debugging tutorial but it's to no avail as commands either don't work on Debian or they just don't make Kwin start logging anywhere so it's useless that I reproduce all these freezes if I don't know how to make that log file. I normally can make it freeze by moving the window in and out ouf the bottom-left corner. https://bugs.kde.org/show_bug.cgi?id=498849
I can confirm, this happens on my machine as well. Cause: infinite loop in src/window.cpp in Window::nextInteractiveMoveGeometry I couldn't track down the exact nature of it, but the infinite "for(;;)" loop doesn't terminate.
In that "for(;;)" loop in src/window.cpp in Window::nextInteractiveMoveGeometry the variable currentTry is being updated, but after about 50 or so iterations, the currentTry vairable (its x, y, left and top properties) stay the same. I can trigger this without fail every time i drag a window up as if trying to push it over the top edge of the screen.
Thank you Rok F for finding this already. I am using kwin_wayland and the problem from #499913 seems to be the same. I limited the for-ever loop to 10k iterations and saw also a lot same currentTry. numer of equal values,top,bottom,left,right: 9994,-0.958381,1396.04,534.103,3094.1 9967,-3.65454,1393.68,2223.67,4783.67 9465,-9.39802,1387.6,511.134,3071.13 9980,-2.15845,1395.17,1736.35,4296.35 (Multi-display setup with some scaling: fhd with 100% and 4k with 150%.) The snap zones from #499913 were already non-zero (10px).
Changing this: // sinces nextMoveResizeGeom is fractional, at best it is within 1 unit of currentMoveResizeGeom if (std::abs(currentMoveResizeGeom.left() - nextMoveResizeGeom.left()) < 1.0 && std::abs(currentMoveResizeGeom.right() - nextMoveResizeGeom.right()) < 1.0 && std::abs(currentMoveResizeGeom.top() - nextMoveResizeGeom.top()) < 1.0 && std::abs(currentMoveResizeGeom.bottom() - nextMoveResizeGeom.bottom()) < 1.0) { break; // Prevent lockup } to all "<= 1.0" is preventing the lock-up for me. Is the calculation flawed or this exit criteria?
I've been experiencing this, I've narrowed the issue down to issues with scaling, and moving around windows that use hardware acceleration (discord, jellyfin media player, youtube videos, etc). I had one monitor set at 125, and the other at 110. When I set them both to 100 I stop getting crashes. If I have the scaling set as I normally would and just move around a window like dolphin or a blank firefox tab, I also get no crashes. With my scaling set and using an app with hardware acceleration, just a few attempts at dragging a window to the top of a display crashes my whole session and I need to reboot. Operating System: EndeavourOS KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.13-1-lts (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X3D 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 5700 XT
(In reply to Markus from comment #5) > Changing this: > // sinces nextMoveResizeGeom is fractional, at best it is within > 1 unit of currentMoveResizeGeom > if (std::abs(currentMoveResizeGeom.left() - > nextMoveResizeGeom.left()) < 1.0 > && std::abs(currentMoveResizeGeom.right() - > nextMoveResizeGeom.right()) < 1.0 > && std::abs(currentMoveResizeGeom.top() - > nextMoveResizeGeom.top()) < 1.0 > && std::abs(currentMoveResizeGeom.bottom() - > nextMoveResizeGeom.bottom()) < 1.0) { > break; // Prevent lockup > } > to all "<= 1.0" is preventing the lock-up for me. > Is the calculation flawed or this exit criteria? Given that the comment says "within 1 unit" it seems that the author forgot to allow for equality. Seems a reasonable asumption if the comment is correct.
I have the same issue and changing from '<' to '<=' the 'if' condition in Window::nextInteractiveMoveGeometry and then patching kwin fixes the freeze. However, now windows can be easily dragged under the top panel and when you try to drag the window in that state it moves slowly. Before changing the code windows wouldn't go under the top panel that easily.
(In reply to Ivan B. from comment #8) > I have the same issue and changing from '<' to '<=' the 'if' condition in > Window::nextInteractiveMoveGeometry and then patching kwin fixes the freeze. > However, now windows can be easily dragged under the top panel and when you > try to drag the window in that state it moves slowly. > Before changing the code windows wouldn't go under the top panel that easily. The operator only fixes part of the problem. The loop can still go through a hundred iterations, lagging the whole system and making the window movement appear slow. There is currently no upper limit on this loop. For my test, i limited the for loop to a max of 20, and it behaves normally, although i don't know what a realistic limit should be.
(In reply to Rok F from comment #9) > (In reply to Ivan B. from comment #8) > > I have the same issue and changing from '<' to '<=' the 'if' condition in > > Window::nextInteractiveMoveGeometry and then patching kwin fixes the freeze. > > However, now windows can be easily dragged under the top panel and when you > > try to drag the window in that state it moves slowly. > > Before changing the code windows wouldn't go under the top panel that easily. > > The operator only fixes part of the problem. The loop can still go through a > hundred iterations, lagging the whole system and making the window movement > appear slow. There is currently no upper limit on this loop. For my test, i > limited the for loop to a max of 20, and it behaves normally, although i > don't know what a realistic limit should be. I've decided to experiment with this code. Limiting the loop to a small value has the same effect as just simply commenting it out all together. Also there is code that runs only when amount of outputs in the workspace is > 1. ( if (workspace()->outputs().count() > 1) ) If I create a virtual output (or connect another screen), then the amount of outputs is > 1 and the code runs. And it fixes the issue with windows going under the panel when dragged (with code changes) and the freeze (with and without code changes)!
I see that the summary has been changed to "On X11, Plasma freezes hard when a window is dragged to the top of the screen", however this happens on both Wayland and X11, not only on X11!
(In reply to Ivan B. from comment #11) > I see that the summary has been changed to "On X11, Plasma freezes hard when > a window is dragged to the top of the screen", however this happens on both > Wayland and X11, not only on X11! That was me - I interpreted the first few comments on this as being the kwin_x11 version of this issue. There is another bug report for the Wayland version: https://bugs.kde.org/show_bug.cgi?id=499913 If both are in fact the same issue, then one can be merged into the other, but I don't know enough to assume that :-) So pending any of that, I wanted to at least make it easier to identify which one was which for now.
I think that the #499913 (https://bugs.kde.org/show_bug.cgi?id=499913) is the same bug as described here. The steps to reproduce it are the same, and the code that apparently causes the freeze (the infinite loop in Window::nextInteractiveMoveGeometry in src/window.cpp) is not specific to either X11 or Wayland, so it should affect both of them. And, at least in my case, on my PC, it does affect both X11 and Wayland, causing a freeze.
I am suffering from the same annoying bug since 6.3 on Archlinux. I confirm that this occurs in both X11 and Wayland sessions & wobbly effect on and off. It is easy to reproduce, just move a window quickly to the 4 corners of the screen and sooner or later the desktop session will be completely frozen. Alt + ImprPant + e is the only way to regain control of the machine. I can´t provide any log or error message.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7225
*** This bug has been marked as a duplicate of bug 493797 ***
Git commit 3db105d2792d3d05e7bd276f9ca16efc1239a200 by Vlad Zahorodnii. Committed on 24/02/2025 at 16:32. Pushed by vladz into branch 'Plasma/6.3'. Workaround hard freeze during interactive move The visibility check uses .toRect() so it can pass if the window position is slightly offscreen, e.g. -0.4. If these errors accumulate too much, the window can start bounce between offscreen positions. This change works around the issue by making nextMoveResizeGeom slowly converge towards currentMoveResizeGeom in more fine grained steps like it's done during interactive resize. This code is going to be rewritten later to get rid of the brute force infinite loop. Related: bug 499913 M +4 -9 src/window.cpp https://invent.kde.org/plasma/kwin/-/commit/3db105d2792d3d05e7bd276f9ca16efc1239a200