Bug 466414 - Plasmashell and kwin_wayland processes exhibit have high CPU usage when no windows are drawn and using "Keep the selection and clipboard the same" and "Text selection: Always save in history" clipboard settings
Summary: Plasmashell and kwin_wayland processes exhibit have high CPU usage when no wi...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard (show other bugs)
Version: git-stable-Plasma/6.1
Platform: Arch Linux Linux
: NOR major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: efficiency, wayland
Depends on:
Blocks:
 
Reported: 2023-02-25 16:59 UTC by David de Cos
Modified: 2024-07-16 14:14 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: Frameworks 6.4
Sentry Crash Report:


Attachments
Video of the described problem (3.84 MB, video/mp4)
2023-02-25 17:21 UTC, David de Cos
Details
htop in a virtual terminal (279.07 KB, image/jpeg)
2023-03-01 15:12 UTC, David de Cos
Details
plasma-org.kde.plasma.desktop-appletsrc file (42.31 KB, text/plain)
2023-06-01 14:24 UTC, David de Cos
Details
plasma-org.kde.plasma.desktop-appletsrc (103.01 KB, text/plain)
2023-06-01 15:38 UTC, kerown
Details
Htop in unfocused konsole (1.80 MB, image/jpeg)
2023-09-22 09:26 UTC, kerown
Details
Video showing the bug in action (328.34 KB, video/webm)
2024-04-23 15:11 UTC, David de Cos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David de Cos 2023-02-25 16:59:00 UTC
SUMMARY
***
I have a CPU monitor applet in my panel. In the last couple of days I started noticing that the bar got filled right after login (as in 100% CPU usage), but as soon as I opened any window, the bar "emptied" (low CPU usage). However, as soon as I minimize or close all the windows, the bar gets filled again!

So it's the opposite of what one would expect:
- No windows: high CPU %
- Any window open: low CPU %

In the next comment I'm attaching a video of the described behavior. Note how the blue bar in the panel grows when there's no windows visible. When I click the Konsole window with htop running, you can see for one second how the plasmashell and kwin_wayland processes were peaking, but go back to low % immediately due to konsole being drawn.

Some other remarks:

- I have confirmed how those two processes get close to 100% by running htop in a virtual terminal.

- This only happens in Wayland, no such behavior in X11.

- Running "plasmashell --replace" doesn't fix it.

***

Operating System: openSUSE Leap 15.4
KDE Plasma Version: 5.27.1
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150400.24.46-default (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-6600U CPU @ 2.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 520
Comment 1 David de Cos 2023-02-25 17:21:41 UTC
Created attachment 156716 [details]
Video of the described problem

Check the size of the blue bar in the panel, depending on whether there are any windows drawn or not. Any time I restore the konsole window, you can see what two processes were peaking a second before.

Ignore the numbers under the bar, those are network speeds.

Sorry for the phone video, I couldn't get a proper screen recording in Wayland.
Comment 2 David de Cos 2023-02-25 17:25:02 UTC
In my first comment it says "Graphics Platform: X11", but that's because I reported the bug from X11. This is obviously a Wayland specific bug.
Comment 3 Nate Graham 2023-02-28 20:37:50 UTC
I don't se any abnormal CPU usage from plasmashell in that video; only kwin_wayland. Is this the case, or am I missing it?
Comment 4 David de Cos 2023-03-01 15:02:26 UTC
The video is quite bad because I had to compress it into less than 4 MB, but if you look closely at the moments when I click on konsole (for example, 29 or 41 seconds into the video), you can see that plasmashell was higher than 80%. It's the first row, in blue. It drops very quickly to low levels, because it only peaks when all windows are minimized (or closed).
Comment 5 David de Cos 2023-03-01 15:12:17 UTC
Created attachment 156876 [details]
htop in a virtual terminal

Since opening any window (like Konsole) makes the peaking processes go to normal levels almost instantly, I'm attaching a picture of htop in a virtual terminal, where I can observe the bug without "disturbing" it.

BTW, going back to Plasma (as in Ctrl+Alt+F7) gets me a crashed desktop, where everything is black, except for the mouse pointer. No panel or icons, no KRunner, nothing. I can only kill the X session, and still have to reboot because most user processes (plasmashell and kwin_wayland among them) stay alive anyway.
Comment 6 Nate Graham 2023-03-01 17:52:10 UTC
Interesting, thanks a lot for the extra info. I wonder if this is related to Bug 466551.
Comment 7 David de Cos 2023-03-03 17:07:47 UTC
I got it wrong: it's not whether windows are open or not, it's whether they are focused or not. So if I have any window selected, the CPU remains at normal levels, but as soon as I click on the desktop background, thus deselecting the window, plasmashell and kwin_wayland go crazy.
Comment 8 David de Cos 2023-03-03 17:13:45 UTC
More interestingly, I don't have this bug in other users of the same computer. So it's definitely something in my particular user that is triggering this.

I'm willing to try to narrow it down by resetting my .local or .config files until it disappears, but I don't want to mess with my home user too much, as this is my work computer. Any ideas as to what files I should try resetting first, given that plasmashell and kwin_wayland seem to be the two processes involved?
Comment 9 kerown 2023-03-14 22:37:59 UTC
I have the same issue with wayland. And similarly, another user doesn't. I noticed it thanks to power monitor: https://github.com/atul-g/plasma-power-monitor. With all windows minimized, the power usage stays at 12-17W vs regular 5-7W. 
Not sure which of my configs would be responsible. I tried removing some widgets but no luck. 
I've got laptop with AMD Ryzen 5 5500U.
Comment 10 David Edmundson 2023-06-01 11:32:48 UTC
Can you attach your .config/plasma-org.kde.plasma.desktop-appletsrc  

There are some wallpapers that try to animate if no windows are shown, that sort of thing would match the symptoms.
Comment 11 David de Cos 2023-06-01 14:24:06 UTC
Created attachment 159392 [details]
plasma-org.kde.plasma.desktop-appletsrc file

Thank you for looking into it, David. Here's the file.

In any case, I later figured out that the bug doesn't only take place when there are no windows shown, it happens when no window is focused. That is, if I've got a window open but I click on the desktop (thus unfocusing the window), the plasmashell and kwin_wayland processes go crazy too.
Comment 12 kerown 2023-06-01 15:38:11 UTC
Created attachment 159395 [details]
plasma-org.kde.plasma.desktop-appletsrc

I attached my plasma-org.kde.plasma.desktop-appletsrc  file too as my symptoms are exactly the same. It's when no windows is in focus that I get the issue. I tried removing all applets but it didn't help.
Comment 13 Bug Janitor Service 2023-06-16 03:45:17 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 14 David de Cos 2023-06-16 09:33:15 UTC
Marking it as REPORTED again.
Comment 15 kerown 2023-09-22 09:07:51 UTC
The bug is still present in 5.27.8 for me. I tried removing plasmashellrc, kwinrc, kwinrulesrc, and defaulting on most settings in systemsettings but it made no difference.
Comment 16 kerown 2023-09-22 09:26:02 UTC
Created attachment 161801 [details]
Htop in unfocused konsole
Comment 17 kerown 2023-10-31 19:24:31 UTC
I removed all the possible plasma configs, I started setting up everything to my preference and I think I know what causes the issue. Could someone test too?

To replicate:
go to clipboard settings and tun on 'Keep the selection and clipboard the same' and 'Text selection: Always save in history'
Comment 18 David de Cos 2023-10-31 20:26:19 UTC
I can confirm that your method to replicate the bug is working for me. Thank you for that, I wouldn't have guessed it was the clipboard settings in a million years!

For anyone willing to look into it, a couple of additional comments:

1) It's specifically the 'Text selection: Always save in history' option that triggers the bug. That is: 'Keep the selection and clipboard the same' together with 'Text selection: Only when explicitly copied' is fine.

2) To experience the bug, you need to select 'Text selection: Always save in history', and relogin. Once you do that, your plasmashell and kwin_wayland processes will peak when no windows have the focus. However, in order to stop the bug, just select again 'Text selection: Always save in history', and the processes will go back to normal immediately. No need to relogin in this case.
Comment 19 kerown 2023-10-31 21:23:55 UTC
(In reply to David de Cos from comment #18)
> I can confirm that your method to replicate the bug is working for me. Thank
> you for that, I wouldn't have guessed it was the clipboard settings in a
> million years!

It is bonkers. I've had some unrelated issue that made me reset everything, otherwise I wouldn't think to check out the clipboard config in a million years. 
Hopefully it will now get fixed as clipboard history is a neat feature to have.
Comment 20 Nate Graham 2023-11-01 17:44:06 UTC
Interesting, I cannot reproduce the issue in Plasma 6 Wayland with that exact combination of settings.
Comment 21 David de Cos 2023-11-01 19:00:50 UTC
(In reply to Nate Graham from comment #20)
> Interesting, I cannot reproduce the issue in Plasma 6 Wayland with that
> exact combination of settings.

It's good to know it's not being carried to Plasma 6!

As for Plasma 5, I think I can say it's always reproducible, at least with Plasma 5.27. I have just reproduced it in two computers, with different:
- OS (Opensuse Tumbleweed and Kubuntu 23.04)
- Users (my primary user and a newly created one)
- Plasma versions (5.27.9 and 5.27.4)
- QT versions (5.15.11 and 5.15.8)
Comment 22 Nate Graham 2023-11-01 19:06:07 UTC
Cool. At the moment almost 100% of the Plasma dev team's focus is on Plasma 6, so unfortunately I doubt anyone will be able to investigate and produce a fix for 5.27.10 (which will be the last Plasma 5 bugfix release). Let's call it fixed for Plasma 6! At least there's that. :)
Comment 23 kerown 2024-01-25 17:13:08 UTC
The bug is present in 5.92.0
Comment 24 David de Cos 2024-01-30 12:17:35 UTC
(In reply to kerown from comment #23)
> The bug is present in 5.92.0

That's unfortunate... I was really eager to switch to Wayland as soon as Plasma 6 landed, but that's a showstopper for me. However, I was under the impression that Nate checked it and couldn't reproduce the bug... maybe it reappeared in a more recent version of Plasma 6?
Comment 25 kerown 2024-02-01 21:28:51 UTC
Same with RC2. As soon as there is something in the clipboard (any text selection in that case) the CPU spikes with windows minimized. I'm guessing it won't be high on priority list with other more critical bugs needing addressing before Plasma 6 release.
Comment 26 David de Cos 2024-03-14 16:03:56 UTC
I can confirm this bug is still present in Plasma 6.0.1, in my case in OpenSUSE Tumbleweed.
Comment 27 kerown 2024-03-14 16:34:00 UTC
(In reply to David de Cos from comment #26)
> I can confirm this bug is still present in Plasma 6.0.1, in my case in
> OpenSUSE Tumbleweed.

Same with 6.0.2
Comment 28 David de Cos 2024-04-23 15:05:00 UTC
This is still present on Plasma 6.0.4, Frameworks 6.1.0, Qt 6.7.0.

As I said in a previous comment, I can reproduce this with different users, distros, computers, etc, so I bet this is general. Just need to go to Clipboard settings, select "Text selection: Always save in history", and relogin.

I'm attaching a new video I just recorded with Spectacle, in case I can lure some hero developer into having a look at this ;-)
Comment 29 David de Cos 2024-04-23 15:11:44 UTC
Created attachment 168841 [details]
Video showing the bug in action

See how the processes differ between this two situations that alternate in the video:
- Click on konsole (a window is focused, normal cpu usage)
- Click on the desktop background (no windows focused, high cpu usage)
Comment 30 kerown 2024-05-25 20:51:41 UTC
Unfortunately, still present in 6.1 beta.
Comment 31 Bug Janitor Service 2024-06-02 09:54:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4394
Comment 32 Bug Janitor Service 2024-06-02 09:54:08 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4394
Comment 33 Bug Janitor Service 2024-06-03 13:39:48 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/121
Comment 34 David Edmundson 2024-06-04 08:49:12 UTC
Git commit 0420025cc0d706856076bb71143c04f857871ac2 by David Edmundson.
Committed on 04/06/2024 at 08:49.
Pushed by davidedmundson into branch 'master'.

clipboard: Add roundtrip when setting clipboard

To avoid deadlocking when copying data, klipper will use the regular
clipboard whilst we have keyboard focus. This is a bit of a hack, but
without better alternatives.

If data is set this way, the check when we receive a new clipboard to
see if we are the owner does not work. Checking
QClipboard::ownsClipboard does not work as we still want to track
changes from other parts of the smae process.

As an alternative, when using this specific path we make it synchronous
so that the change signal can be ignored.
FIXED-IN: 6.3

M  +4    -0    src/systemclipboard/waylandclipboard.cpp

https://invent.kde.org/frameworks/kguiaddons/-/commit/0420025cc0d706856076bb71143c04f857871ac2
Comment 35 Fushan Wen 2024-06-04 11:27:09 UTC
Git commit 2796e85d0e4e98ab0345890d3c58847ea26c22f6 by Fushan Wen.
Committed on 04/06/2024 at 11:07.
Pushed by fusionfuture into branch 'master'.

appiumtests: test empty clip crashes klipper
Related: bug 487843

M  +1    -1    appiumtests/applets/CMakeLists.txt
M  +43   -2    appiumtests/applets/clipboardtest.py

https://invent.kde.org/plasma/plasma-workspace/-/commit/2796e85d0e4e98ab0345890d3c58847ea26c22f6
Comment 36 Bug Janitor Service 2024-06-04 11:41:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4407
Comment 37 David de Cos 2024-06-04 12:02:32 UTC
Much appreciated! This was a showstopper for me as it messed with my workflow, so I'll be happily switching to Wayland once this lands. Thank you!
Comment 38 Fushan Wen 2024-06-04 12:02:35 UTC
Git commit eb016cf60c9aaf37b9faf65b52abe51b4dd85eb0 by Fushan Wen.
Committed on 04/06/2024 at 11:41.
Pushed by fusionfuture into branch 'Plasma/6.1'.

appiumtests: test empty clip crashes klipper
Related: bug 487843


(cherry picked from commit 2796e85d0e4e98ab0345890d3c58847ea26c22f6)

Co-authored-by: Fushan Wen <qydwhotmail@gmail.com>

M  +1    -1    appiumtests/applets/CMakeLists.txt
M  +43   -2    appiumtests/applets/clipboardtest.py

https://invent.kde.org/plasma/plasma-workspace/-/commit/eb016cf60c9aaf37b9faf65b52abe51b4dd85eb0
Comment 39 kerown 2024-07-13 10:14:12 UTC
It does seem to be fixed for me with version 6.4.0 of kguiaddons. Thank you!
Comment 40 David de Cos 2024-07-16 14:14:11 UTC
I can confirm it's fixed in openSUSE Tumbleweed too. Thank you very much!