Created attachment 178222 [details] kwin_wayland process information in journal Hi, I noticed that dragging windows with the mouse until the top edge of the screen is highlighted in blue, and then dragging the window further down, until the blue border disappears, if I repeat this gesture quickly, the desktop freezes and no longer responds to mouse and keyboard. However, it is possible to access in ssh and see the kwin_wayland process occupying 100% of the cpu. Killing this process everything resumes. If you do not intervene in ssh, then the magic sequence of kernel reboot REISUB is needed to restart the server (even if it still creates problems for mounted partitions). In detail the information relating to this process, detected by the journal. Same problems with the previous plasma version 6.2.5 Thanks, Antonio SUMMARY STEPS TO REPRODUCE 1. open any window, for example konsole terminal; 2. drag the window with the mouse up on the screen until the colored border appears; 3. still holding the left mouse button pressed, drag the window further down, until the colored border disappears; 4. always keeping the left mouse button pressed, quickly repeat this operation several times. OBSERVED RESULT after a few seconds the desktop freezes and you can't interact with the mouse and keyboard. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 Kernel Version: 6.12.13-2-liquorix-amd64 (64-bit) Graphics Platform: Wayland Processors: 24 × 12th Gen Intel® Core™ i9-12900T Memory: 31.1 GiB of RAM Graphics Processor: Intel® UHD Graphics 770 Manufacturer: ASUS ADDITIONAL INFORMATION process detected 100%: ---> Sl /bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/0/xauth_RDCUHv --xwayland journal: ---> view attachment
I found, the problem is in: systemsettings -> windows management -> window behavior -> movement when both entries: - screen edge snap zone - windows snap zone are set to 0 if I insert 1px in at least one of these entries it solves. it is necessary to prevent this possibility to not compromise the stability of the desktop (or solve the problem for which kwin_wayland goes to 100% of the cpu, else it blocks everything).
I can reproduce on Debian (unstable repository) With: SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 Kernel Version: 6.12.13-amd64 (64-bit) Graphics Platform: Wayland HARDWARE SPECIFICATIONS Hardware: Laptop Dell Inspiron 5770 (17" 1080p@60Hz screen) CPU: Intel® Core™ i5-8250U CPU @ 1.60GHz GPU 1: Mesa Intel® UHD Graphics 620 (main) GPU 2: AMD Radeon R5 M465 Series RAM: 8 GiB (7.7 GiB usable) I forgot to look at the CPU usage when I did the test.
Note that what is said is only valid on plasma 6.2.5, while on version 6.3.0 the frequency has been reduced, but the problem remains.
same problem updating OpenSuse to version 6.3.0 Operating System: openSUSE Tumbleweed 20250211 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Graphics Platform: Wayland
For what it's worth, there's some investigation in the comments for the X11 equivalent of this bug - https://bugs.kde.org/show_bug.cgi?id=500015 - that seems like it's also relevant to Wayland.
mine plasma version is 6.3 same things happend on me too what happend: when i grab a window and put it on top of desktop and move left and right quickly the windows will move slow and can not follow up the mouse, and after that, the whole system just stucked at a frame no action for any input, can not switch to other TTYs, and my computer fan is going to take off on mine device, its not happend on X11, only wayland (In reply to antonio from comment #1) > I found, the problem is in: > > systemsettings -> windows management -> window behavior -> movement > > when both entries: > - screen edge snap zone > - windows snap zone > > are set to 0 > > if I insert 1px in at least one of these entries it solves. > > it is necessary to prevent this possibility to not compromise the stability > of the desktop (or solve the problem for which kwin_wayland goes to 100% of > the cpu, else it blocks everything). on my setting their default var is 10px, but same bug still happend logs here: [line0] hardware [line1049] journalctl [line3990] Kwin.supportInfomation [line4364] https://gist.github.com/LightBlueCube/72a3f511393c51eb86f14af6ba04c0d8
*** Bug 500250 has been marked as a duplicate of this bug. ***
Just FYI, I can reproduce it on Fedora too (Fedora 41, Qt 6.8.2, Frameworks 6.11, Plasma 6.3.0 wayland). I had 5 px in both options mentioned previously, still randomly freezing when I drag a window and the handle is close to the top border.
The same happens using kwin_x11.
While confirming this report, I just wanted to add that having a Plasma session isn't required for triggering it. I encountered it with LXQt+kwin_wayland after maximizing a window by dragging it from its titlebar. Only a hard reset was possible.
I think this is the return of a bug I reported over a year ago: https://bugs.kde.org/show_bug.cgi?id=479786 There may be some useful info in the previous thread.
(In reply to TheFeelTrain from comment #11) > I think this is the return of a bug I reported over a year ago: > https://bugs.kde.org/show_bug.cgi?id=479786 > > There may be some useful info in the previous thread. Interestingly, reverting to "<= 1.0" was also suggested in https://bugs.kde.org/show_bug.cgi?id=500015#c5 (see https://invent.kde.org/plasma/kwin/-/merge_requests/5468/diffs?commit_id=701f9140816477d1b8e2618cd72e8c1d02c3df6b).
I started experiencing this bug a few weeks ago, possibly with the update to 6.3.0. I just updated to plasma 6.3.1 this morning and the bug is still present. The cursor changes to a hand (window move) and everything freezes. The only solution appears to be a complete restart. OS: Gentoo Linux x86_64 Kernel: Linux 6.13.2-gentoo Uptime: 15 mins Shell: bash 5.2.37 Display (DELL U2412M): 1920x1200 @ 60 Hz in 24" [External] * Display (DELL U2412M): 1920x1200 @ 60 Hz in 24" [External] DE: KDE Plasma 6.3.1 WM: KWin (X11) WM Theme: Oxygen Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3/4] Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4] Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4] Cursor: breeze (24px) Terminal: konsole 24.12.2 CPU: Intel(R) Core(TM) i7-5820K (12) @ 3.60 GHz GPU: NVIDIA GeForce RTX 3060 Lite Hash Rate [Discrete]
The change mentioned at https://bugs.kde.org/show_bug.cgi?id=500015#c5 worked for me (with kwin_wayland). But the compilation of KWin took a long time and made my CPU temperature reach 95°C; so, I won't do it again ;)
I just tried the change suggested by https://bugs.kde.org/show_bug.cgi?id=500015#c5. This appears to prevent the freeze. I can now move a window quickly near the screen edge.
plasma also crashes when dragging the window down, with the window title just above the main panel (which in my case is at the bottom and configured as non-floating), repeating the movement multiple times... can you check if the fix is valid in this case too?
(In reply to antonio from comment #16) > plasma also crashes when dragging the window down, with the window title > just above the main panel (which in my case is at the bottom and configured > as non-floating), repeating the movement multiple times... can you check if > the fix is valid in this case too? I tried multiple moving a window rapidly with the title just above the main panel multiple times and I did not experience any freeze. That said, after a few hours of stability I hit another freeze. Unfortunately https://bugs.kde.org/show_bug.cgi?id=500015#c5 is an improvement but not a solution.
(In reply to Jean-Francois Ostiguy from comment #17) > Unfortunately https://bugs.kde.org/show_bug.cgi?id=500015#c5 is an improvement but not a solution. It's definitely not a fix, but only a way of avoiding the bad freeze (which hasn't happened here since that change), until the bug is really fixed by KWin devs.
I think it would be useful to also include a thread in the program that monitors CPU usage and kills the process in case of excessive and prolonged CPU usage (for example over 95% CPU for more than 10 consecutive seconds), because killing this process restarts Plasma without affecting any open windows on the screen and can be a solution to prevent the server freeze in case of undetected bugs.
Waiting for the bug to be fixed, I attached a temporary patch to avoid the desktop freeze, exiting the loop after a few seconds, I recompiled the source for debian and verified: even if the bug is not solved, in case of freeze the desktop now unlocks after 5 seconds. I confirm however that the problem is in src/windows.cpp in the lines with the "for(;;)" loops.
--- test/kwin-6.3.0/src/window.orig 2025-02-06 12:01:48.000000000 +0100 +++ test/kwin-6.3.0/src/window.cpp 2025-02-21 15:06:37.885455302 +0100 @@ -50,6 +50,12 @@ #include <QMouseEvent> #include <QStyleHints> +#include <time.h> +#include <unistd.h> +time_t maxtime=5; +useconds_t waitmsec=10; + + namespace KWin { @@ -1542,7 +1548,9 @@ int lastVisiblePixels = -1; QRectF lastTry = nextMoveResizeGeom; bool titleFailed = false; - for (;;) { + time_t starttime=time(NULL); + while((time(NULL)-starttime)<maxtime) { + usleep(waitmsec); const QRect titleRect = bTitleRect.translated(nextMoveResizeGeom.topLeft()).toRect(); const int requiredPixels = std::min(100 * (transposed ? titleRect.width() : titleRect.height()), titleRect.width() * titleRect.height()); @@ -1665,7 +1673,9 @@ } bool transposed = false; QRectF bTitleRect = titleBarRect(nextMoveResizeGeom, transposed); - for (;;) { + time_t starttime=time(NULL); + while((time(NULL)-starttime)<maxtime) { + usleep(waitmsec); QRectF currentTry = nextMoveResizeGeom; const QRect titleRect = bTitleRect.translated(currentTry.topLeft()).toRect(); const int requiredPixels = std::min(100 * (transposed ? titleRect.width() : titleRect.height()), titleRect.width() * titleRect.height());
(In reply to antonio from comment #16) > plasma also crashes when dragging the window down, with the window title > just above the main panel (which in my case is at the bottom and configured > as non-floating), repeating the movement multiple times... can you check if > the fix is valid in this case too? The same for me, up and down: always crash. I also see a difference between x11 and wayland when dragging a window to the task bar: In x11 the titlebar never hides behind the taskbar, but in wayland yes. Today I upgraded my system to Plasma 6.3.1 and there is no fix yet =S
I tried to use the system with the proposed patch and it seems to work well, I just lowered the maxtime value to 1 second, by doing so I don't even notice the problem and for the moment it's fine, I can work without the risk of the desktop freezing.
(In reply to antonio from comment #1) > I found, the problem is in: > > systemsettings -> windows management -> window behavior -> movement > > when both entries: > - screen edge snap zone > - windows snap zone > > are set to 0 > > if I insert 1px in at least one of these entries it solves. > > it is necessary to prevent this possibility to not compromise the stability > of the desktop (or solve the problem for which kwin_wayland goes to 100% of > the cpu, else it blocks everything). I set the following to 35px and does not crash kwin: - Screen edge snap zone - Window snap zone - Center snap zone I've not tested to deeply on other zone sizes, but that size works for me for the time being.
(In reply to Hidden Bug from comment #24) > (In reply to antonio from comment #1) > > I found, the problem is in: > > > > systemsettings -> windows management -> window behavior -> movement > > > > when both entries: > > - screen edge snap zone > > - windows snap zone > > > > are set to 0 > > > > if I insert 1px in at least one of these entries it solves. > > > > it is necessary to prevent this possibility to not compromise the stability > > of the desktop (or solve the problem for which kwin_wayland goes to 100% of > > the cpu, else it blocks everything). > I set the following to 35px and does not crash kwin: > - Screen edge snap zone > - Window snap zone > - Center snap zone > > I've not tested to deeply on other zone sizes, but that size works for me > for the time being. I tried the values indicated and by doing so it does not block, probably with these values kwin is able to complete the routine. It could also depend on the height of the window border and therefore on the theme in use (i use default: breeze). However, even if this seems to work, I would not rely on luck, considering that the desktop is a vital element of the system. Therefore, even when the problem is solved, in my opinion there should always be an emergency clause that avoids the infinite loop, to cover those errors that do not come out immediately and that have not yet been considered. I hope these analysis will help to fix this bug.
(In reply to antonio from comment #25) > (In reply to Hidden Bug from comment #24) > > (In reply to antonio from comment #1) > > > I found, the problem is in: > > > > > > systemsettings -> windows management -> window behavior -> movement > > > > > > when both entries: > > > - screen edge snap zone > > > - windows snap zone > > > > > > are set to 0 > > > > > > if I insert 1px in at least one of these entries it solves. > > > > > > it is necessary to prevent this possibility to not compromise the stability > > > of the desktop (or solve the problem for which kwin_wayland goes to 100% of > > > the cpu, else it blocks everything). > > I set the following to 35px and does not crash kwin: > > - Screen edge snap zone > > - Window snap zone > > - Center snap zone > > > > I've not tested to deeply on other zone sizes, but that size works for me > > for the time being. > > I tried the values indicated and by doing so it does not block, probably > with these values kwin is able to complete the routine. It could also > depend on the height of the window border and therefore on the theme in use > (i use default: breeze). > However, even if this seems to work, I would not rely on luck, considering > that the desktop is a vital element of the system. > Therefore, even when the problem is solved, in my opinion there should > always be an emergency clause that avoids the infinite loop, to cover those > errors that do not come out immediately and that have not yet been > considered. > I hope these analysis will help to fix this bug. I think we should use kwin's logging mechanism to log when the while loop exits via the above proposed exit clause.
I doing tests I narrowed the problem to the second loop, in the "Window::nextInteractiveMoveGeometry" function, relating to the condition: // since 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 } I traced on file the values when the freeze occurred: freeze top: (256.976 257.976), (1547.98 1548.98), (-1.86822 -1.86822), (983.132 983.132) freeze bottom: (413.755 415.755), (1704.75 1706.75), (1012.65 1012.65), (1997.65 1997.65) so based on the detected values I changed the condition (from "<1.0" to "<=1.0"): 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 } and it seems to work well on both the top and bottom edges. I tried both, with 10px default and with 0px, for now no freeze.
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 ***
(In reply to Bug Janitor Service from comment #28) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kwin/-/merge_requests/7225 IMHO, a `for (;;)` loop is always dangerous, unless there's an explicit way of breaking it *without relying on a logic outside it*.
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 500015 M +4 -9 src/window.cpp https://invent.kde.org/plasma/kwin/-/commit/3db105d2792d3d05e7bd276f9ca16efc1239a200
(In reply to Tsu Jan from comment #30) > (In reply to Bug Janitor Service from comment #28) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/kwin/-/merge_requests/7225 > > IMHO, a `for (;;)` loop is always dangerous, unless there's an explicit way > of breaking it *without relying on a logic outside it*. A full resolution of the issue is being worked on in https://invent.kde.org/plasma/kwin/-/merge_requests/5296.
(In reply to Tsu Jan from comment #30) > (In reply to Bug Janitor Service from comment #28) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/kwin/-/merge_requests/7225 > > IMHO, a `for (;;)` loop is always dangerous, unless there's an explicit way > of breaking it *without relying on a logic outside it*. with that MR, the geometries should always converge