SUMMARY *** Plasmashell will hang after desktop switch, with one core showing 100% CPU utilization, when a custom *.desktop file is pinned in Task Manager *** Creating a custom app.desktop which runs a shell command when clicked and adding it (to be "pinned") in icons-only Task Manager creates a reproducible hang for extended period when switching desktops. Plasmashell will show in top as using 100% CPU and it takes quite a while for the condition to resolve itself. Profiling with perf shows a lot of system calls. Profiling with strace shows that the app.desktop file keeps being repeatedly accessed. A typically pattern is several lstat() calls walking directory tree two access() calls and then an openat() call. This repeats for a while. Note that the symptoms of this hang are similar to the hang one gets when running plasmashell for extended time, except that in this case the problem is triggered by adding the app.desktop to Task Manager, and is fixed by unpinning the icon. It can be triggered again by adding the icon back. It might (or might not) be relevant that I have a lot of other windows, in particular Firefox opened at the same time. Firefox does have KDE integration enabled. Also, I have plasmashell panel with Task manager on the right side of the screen (not the bottom). STEPS TO REPRODUCE 0. A plasmashell desktop that has been in use for a while - many firefox windows, many kwrite windows. Plasmashell panel on the right side of the screen. Some kwrite windows slid under the panel on the right. 1. Create a custom app.desktop and add it Task manager. 2. Switch desktops OBSERVED RESULT 100% CPU usage by plasmashell in top. Significant delay before this is resolved. EXPECTED RESULT No delay in responsiveness when switching desktops. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Ubuntu 20.04 Intel 64-bit.
Sorry no one got back to you about this bug earlier. Are you able to reproduce the issue with Plasma 5.27.4 or newer?
Not sure - I am using Kubuntu 20.04, currently running plasma 5.18.8, Is it still the case that to try new plasmashell one needs to replace the whole KDE ? On Tue, 11 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |nate@kde.org > > --- Comment #1 from Nate Graham <nate@kde.org> --- > Sorry no one got back to you about this bug earlier. Are you able to reproduce > the issue with Plasma 5.27.4 or newer? > > -- > You are receiving this mail because: > You reported the bug.
Yes. I would strongly recommend upgrading; Plasma 5.18 has been out of support for years. If you upgrade to Kubuntu 22.04, you'll at least get Plasma 5.24, which is still out of support, but it's much newer and less buggy. And then you can upgrade to Kubuntu 23.04 once it's released this month and get Plasma 5.27, which is supported and will be supported through the end of the year at least.
Created attachment 158080 [details] Light.desktop Oh, I see - is there a straightforward way to install the latest version to test without upgrading the whole distribution ? Years ago I was happily compiling KDE and it was often possible to compile one component at a time. Once I even compiled it for Solaris - was a major improvement over CDE. For me the key thing is stability of tools like gcc and system libraries - upgrading the distribution changes versions and then I need to retest my code again for speed. That's why I stick to LTS versions of Ubuntu. Btw, if you have the newest version installed, maybe you could run a quick test ? All one needs to do is to create a KDE desktop file pointing to any executable, assign an icon to it and pin it in the task manager. The if switching desktops is seamless, chances are it is fixed in the newest version. I also attached my Light.desktop file in case it is useful. thank you Vladimir Dergachev On Thu, 13 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #3 from Nate Graham <nate@kde.org> --- > Yes. I would strongly recommend upgrading; Plasma 5.18 has been out of support > for years. If you upgrade to Kubuntu 22.04, you'll at least get Plasma 5.24, > which is still out of support, but it's much newer and less buggy. And then you > can upgrade to Kubuntu 23.04 once it's released this month and get Plasma 5.27, > which is supported and will be supported through the end of the year at least. > > -- > You are receiving this mail because: > You reported the bug.
Yep, I don't experience the bug with that .desktop file pinned to my Task Manager. So let's call it fixed! It's always possible to compile a new Plasma on an old distro, but the older the distro, the harder it will be since Plasma frequently depends on relatively new versions of 3rd-party libraries. I'd file it under "possible but painful" (or adventurous, depending on how you want to look at it!). Also JFYI you probably need to be testing your code for speed and correctness with new tooling as well as old tooling, because you can't guarantee that all of your users will be using software compiled with old tooling, unless you distribute the software yourself in purely binary form. As long as the source code is available, any random distro can compile it with any tooling and package it up for consumption.
On Fri, 14 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|WAITINGFORINFO |FIXED > Status|NEEDSINFO |RESOLVED > > --- Comment #5 from Nate Graham <nate@kde.org> --- > Yep, I don't experience the bug with that .desktop file pinned to my Task > Manager. So let's call it fixed! Agreed ! > > It's always possible to compile a new Plasma on an old distro, but the older > the distro, the harder it will be since Plasma frequently depends on relatively > new versions of 3rd-party libraries. I'd file it under "possible but painful" > (or adventurous, depending on how you want to look at it!). > > Also JFYI you probably need to be testing your code for speed and correctness > with new tooling as well as old tooling, because you can't guarantee that all > of your users will be using software compiled with old tooling, unless you > distribute the software yourself in purely binary form. As long as the source > code is available, any random distro can compile it with any tooling and > package it up for consumption. No, no, this is a different situation - this is a numerical code and speed is critical, so one needs to control assembly output. So I want the C compiler to produce a binary where inner loops do exactly what I want. When you upgrade distros gcc and C libraries often have large changes. A lot of those changes are well-intentioned attempts to automatically secure programs against bugs or introduce speedups into poorly optimized programs, at the expense of numerical codes such as mine. So I compare runtime between different binaries and start digging into assembly to figure out what went wrong. This fine tuning is worthwhile because the code takes months to run. It is the results that are distributed to the users - they are portable and use MVL library (package RMVL if you use R). thank for looking into this ! Vladimir Dergachev > > -- > You are receiving this mail because: > You reported the bug.
Oh wow, what an interesting use case. It's always cool to hear about all the diverse ways people use our software!