I use KDE plasma in Wayland mode (kwin is the Wayland compositor) on Gentoo Linux. Last week I updated to: - kde-plasma 5.16.0 - kde-frameworks 5.59.0 - kde-apps 19.04.2 After that, my screen randomly froze once or twice a day. Today I found out that I can trigger a freeze by starting Wireshark-3.0.2 from konsole: GUI freezes, mouse disappears, top shows 100% CPU for /usr/bin/kwin_wayland, Alt-Ctrl-Fn or Ctrl-BS don't work. I downgraded kde-plasma/kwin to 5.15.5 (only this package). I haven't had any freezes since then and I can start Wireshark-3.0.2 without problems. Reproducible: Always Steps to Reproduce: 1. Login as ordinary user on Linux TTY console 2. Start GUI (KDE Plasma) with 'startx' 3. open a konsole terminal 4. enter 'wireshark' 5. GUI freezes, mouse disappears, top shows 100% CPU for /usr/bin/kwin_wayland SOFTWARE/OS VERSIONS - Gentoo Linux: default/linux/amd64/17.1/no-multilib - Linux Kernel: 4.19.50 - GCC: 8.3.0 - KDE Plasma Version: 5.16.0 - KDE Frameworks Version: 5.59.0 - KDE Apps: 19.04.2 - Qt Version: 5.12.3 ADDITIONAL INFORMATION I also filed a bug at: https://bugs.gentoo.org/688128
>2. Start GUI (KDE Plasma) with 'startx' >5. GUI freezes, mouse disappears, top shows 100% CPU for /usr/bin/kwin_wayland you run startx to get a wayland session?
> you run startx to get a wayland session? My fault. I'm sorry. I run a script 'startk' and its contents is export XDG_SESSION_TYPE=wayland export $(dbus-launch) && startplasmacompositor
Could be the same as bug 406548
Created attachment 120906 [details] kwin_wayland gdb backtrace I was able to write a gdb backtrace. 1) I started Plasma, opened a konsole window and started 'wireshark' 2) The GUI froze 3) I connected from another machine via SSH 4) kwin_wayland was running with a load of 100% 5) I started GDB and attached to the kwin_wayland process 6) I created the backtrace
One more observation. I was able to reproduce the freeze reliably with 'wireshark'. I changed a few settings in 'systemsettings' and the error was gone. It never happened again. Then I restored my home directory from a backup - and the error was back: the freeze occurred every time I started 'wireshark'. It might well be that the error only occurs with certain system settings - or after you migrated from an older version of KDE Plasma.
>Created attachment 120906 [details] That seems plausible, I did move when we do the initial placement with 5.16 Can you do that again with debug symbols for kwin and/or upload your kwinrc with the backup that causes the breakage.
I did some more tests. Comment #5 is wrong. I am able to reproduce this error with a new user account. So the problem is not related to a migration from a previous release. One more observation: the error occurs *only* if the Wireshark window was maximized in a previous session. So here is a better version of 'Steps to Reproduce': 1) Create a new user (or delete all configuration files) 2) Start Plasma in Wayland mode 3) open a konsole terminal 4) enter wireshark 5) a wireshark window will pop up. Double-klick on the title bar to maximise it 6) Close Wireshark using File/Quit 7) enter wireshark in konsole terminal 8) GUI freezes, mouse disappears, top shows 100% CPU for /usr/bin/kwin_wayland My screen has a resolution of 1920x1200 pixels. > Can you do that again with debug symbols for kwin I'd like to do that, but I don't fully understand how to do it. Which CFLAGS and cmake options do you want me to use for kwin? Do you want me to create another backtrace with debug symbols on? Or will there be a debug log file if I run kwin with debug symbols on? Please point me to a HOWTO.
Created attachment 120949 [details] kwin_wayland gdb backtrace with debug symbols Andreas Sturmlechner showed me how to compile packages with debug symbols on. I repeated the test and created another backtrace.
Created attachment 120955 [details] (KSysGuard) kwin_wayland memory I can confirm this on KDE Neon 5.16. When I switched to Wayland session at login screen, kwin_wayland was running with a load of ~25% (KSysGuard) CPU and memory ram was increase, cursor was sluggish moving, GUI was sluggish responding. Here my machine info: SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.16 User Edition KDE Plasma Version: 5.16.0 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kernel Version: 4.18.0-21-generic Graphics: Card-1: Intel Skylake GT2 [HD Graphics 520] Card-2: NVIDIA GM108M [GeForce 930M] Display Server: x11 (X.Org 1.19.6 ) drivers: modesetting,nvidia (unloaded: fbdev,vesa,nouveau) Resolution: 1366x768@60.32hz OpenGL: renderer: GeForce 930M/PCIe/SSE2 version: 4.6.0 NVIDIA 390.116
Thanh, thanks for your post! I'm not sure that we talk about the same bug: - In your case, there seems to be a memory leak - I don't see a memory leak. - In your case, mouse and GUI are still responding (although sluggish) - in my case, desktop, keyboard and mouse freeze immediately. What you describe looks more like bug 407612. On the other hand, it well could be that we all suffer from the same problem.
I installed plasma-5.16.1 today and I repeated the test. The bug is still there.
I see what's wrong. We can infinite loop if we're placing a window with an invalid size in some conditions. Will fix.
*** Bug 409036 has been marked as a duplicate of this bug. ***
Git commit 842b2ce51b6b9471f45f94e00a942c52648e9b60 by David Edmundson. Committed on 24/06/2019 at 20:59. Pushed by davidedmundson into branch 'Plasma/5.16'. [placement] Avoid smart placement strategy with invalid client sizes Summary: To do so can in some situations lock up as the loop goes through different positions incrementing by client->width/height. If this is zero we can get into a stuck state. This became a more common issue due to my earlier patch that places windows in ShellClient::finishInit to allow the maximize placement strategy to set the first configure size. Reviewers: #kwin, broulik Reviewed By: broulik Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21997 M +4 -0 placement.cpp https://commits.kde.org/kwin/842b2ce51b6b9471f45f94e00a942c52648e9b60
I updated to Plasma 5.16.2. I can confirm that the bug has been fixed. Thanks! :-)