SUMMARY I have been observing a repeatable issue with Plasmashell and kwin_wayland both suddenly having high CPU usage (each go to about 15-17 percent, total around 33-35% on a quad-core iMac12,2 from 2011), and then a Plasmashell core dump and crash/restart of Plasmashell after quitting the app (GNOME Text Editor) that seems capable of triggering the high CPU usage. Nothing visible happens, but the events can be seen by watching the CPU graph with btop and looking at the journal. Observed repeatedly in testing on openSUSE Tumbleweed, with Plasma 6.1.1. Does not seem to happen on Fedora 40, also with Plasma 6.1.1. Both distros originally had GNOME and the KDE desktop package patterns were added later. Other than some mix-ups with which file manager should open directories with `xdg-open` and other minor things associated with having multiple desktop environments installed on the same system, there have been no real problems observed on either system, until this Plasmashell core dumping was observed. Sometimes a dialog appears after Plasmashell crashes, and I submit the crash report each time. Other times it does not appear. STEPS TO REPRODUCE 1. Install Tumbleweed with Plasma, latest updates. 2. Install GNOME Text Editor 3. Open GNOME Text Editor, and start typing a block of random text. 4. Select all the text and delete it with Backspace. This triggers the high CPU usage phase, which will continue until the text editor app is quit. 5. Quit the text editor. Plasmashell core dumps and gets restarted. CPU usage returns to normal (3-4% rather than 35-39%). SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed with 20240629 update KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2
> Sometimes a dialog appears after Plasmashell crashes, and I submit the crash report each time Thanks for that. Since the crash reports are already automatically submitted, I'm not sure there's anything actionable for us here — especially because it happens on a franken-system with GNOME and Plasma both installed. It's not that this is invalid, but... there be dragons. Neither the GNOME nor KDE developers are testing this configuration or have any interest in formally supporting it. It's a niche of a niche of a niche of a niche. Thanks again for the automatic crash reports!
(In reply to Nate Graham from comment #1) > > Sometimes a dialog appears after Plasmashell crashes, and I submit the crash report each time > Thanks for that. Since the crash reports are already automatically > submitted, I'm not sure there's anything actionable for us here — especially > because it happens on a franken-system with GNOME and Plasma both installed. > It's not that this is invalid, but... there be dragons. Neither the GNOME > nor KDE developers are testing this configuration or have any interest in > formally supporting it. It's a niche of a niche of a niche of a niche. > > Thanks again for the automatic crash reports! I appreciate all that you do to make KDE better, Nate. But I will always disagree with the idea that it is unimportant to find out why one of your own pieces of software, especially things as central as the shell and KWin, is allowing itself to go nuts on the CPU and then core dump just because a GTK app user deletes some text and then later quits the GTK app. I don't think the "fraken-system" status is ever going to be a good excuse not to take a close look at such things. There do be dragons, but each individual desktop environment and all its components should endeavor to be resilient even in a mixed environment. Especially when everyone is moving toward things like Flatpak, where more than half the apps available are probably GTK-based. After all, it was not the GTK app that was using up CPU and crashing. It was Plasmashell (and kwin_wayland, although I'm not aware of KWin ever crashing, and can't tell which of the two is reacting to the other during the high CPU usage). The lack of resilience is obviously somewhere in Plasmashell. The GTK app was just the trigger. If there are additional logs that would help and aren't included in the automatic report, I can try to attach them. I'll also try to remember to come back here and update if the issue goes away with 6.1.2 or some other coming update on Tumbleweed. Perhaps you can let this stay open at least for a week or so before abandoning the idea of finding out why it is happening, just because the system also has some GNOME packages installed.
That said, thanks for pushing me to be better, since it turns out I can reproduce the issue in my own system which does not have GNOME installed, so it doesn't look like that's related. Being able to reproduce the issue makes it actionable.
A flame graph shows that it's in clipboard code, first KSystemClipboard::changed, then SystemClipboard::checkClipData, then SystemClipboard::receivedEmptyClipboard, then WaylandClipboard::setMimeData(). Perhaps the app is sending endless empty clipboard events. We can probably be more robust against this kind of abuse.
(In reply to Nate Graham from comment #4) > A flame graph shows that it's in clipboard code, first > KSystemClipboard::changed, then SystemClipboard::checkClipData, then > SystemClipboard::receivedEmptyClipboard, then > WaylandClipboard::setMimeData(). > > Perhaps the app is sending endless empty clipboard events. We can probably > be more robust against this kind of abuse. Now we're getting somewhere. If it's the specific app that's misbehaving, I can try to push a bug report to the maintainers. Did you also use GNOME Text Editor to trigger the issue? And from a native Package? Mine's coming from the native Tumbleweed package, version 46.3-1.2.x86_64. I haven't actually tried to replicate with a Flatpak. But regardless of whether it is the app doing something bad, some sort of limit should be placed in the appropriate spot in Plasmashell. It's also kind of funny to me that Plasmashell deals just fine with this as long as the app is running, just using a lot of CPU, but then core dumps when the GTK app quits. Like it can't handle getting the rug pulled from under it at the end. The CPU burning can go on for quite a long time without any spontaneous crash. Aaaand I just installed the Flatpak version, ran it, typed a bit, selected and deleted the text, and triggered the same bug. And crash after quitting the app. Second try, I just typed a single letter and then selected/deleted it. Same thing. Typed some more text, saved the file. That did not seem to stop the CPU usage. But what does seem to stop the CPU usage is just making another selection of text. It doesn't even seem to be necessary to copy/cut the selection. Plasmashell seems to return to normal operation as soon as the selection is made.
Native package for GNOME Text for me too. FWIW I can't reproduce plasmashell crashing when the app quits, at least not with everything built from git master. I think we need to investigate what's happening a bit more before we can point the finger at the app. Maybe it's misbehaving and Plasma isn't robust enough, or maybe it's doing something quirky but okay and Plasma is freaking out for no good reasons. Needs further investigation.
(Had a "mid-air collision" with your comment when I tried submit this a minute ago.) Slightly nuanced addition. I'm having a hard time going back to the RPM version to check this because for some reason the Flatpak version replaced the instance of Text Editor in the launcher menu. Even Ulauncher doesn't show more than one "Text Editor", and when I launch it it's the Flatpak version. Anyway, with the Flatpak I can revert the CPU usage by simply selecting some new text, yet if I then unselect that new text (without deleting it while selected), the high CPU usage immediately returns. Until I select text again. There's no cutting/copying or deleting involved in this case. Just selecting. But now, attempting to select text and copy it, avoid deleting it, then continue typing, the high CPU usage also still comes right back. So once this cycle starts it appears to want to continue until the app quits. The dialog about Plasmashell crashing has never shown up so far with the Flatpak, even though I've done the same process of causing the high CPU usage and then quitting the app quite a few times. It was usually about 50/50 with the crash dialog while using the RPM version of the app.
Was able to get the core dump dialog to show up again after running the RPM version from the terminal and doing the usual stuff, then quitting the app. It's apparently only the desktop entry that was overwritten, and that's really weird because I thought all Flatpak desktop entry files were kept in special Flatpak locations to avoid this kind of collision. Might have to file a bug report with openSUSE about that. Since it's also affecting Ulauncher, I'm assuming this is something quirky about openSUSE, or the Flatpak installer screwing up. The RPM is version 46.3. Some info from the troubleshooting dialog in "About": Glib: 2.80.3 (2.80.2) GTK: 4.14.4 (4.14.4) GtkSourceView: 5.12.1 (5.12.0) Libadwaita: 1.5.1 (1.5.0) Enchant2: 2.2.15
Another minor nuance: If I make a text selection to temporarily stop the high CPU usage, and only then quit the app, the RPM version does not seem to trigger the Plasmashell core dump. I've only done it a few times, but this seems to indicate that the core dump is dependent on the cycle that is causing the high CPU usage to be in progress at the moment the app quits. Like Plasmashell is in the middle of expecting something that suddenly isn't there, so it falls on its face. That exact spot definitely needs some safety rails.
I should have realized this since it's about the clipboard being empty, but there's no necessity of deleting any text to start the cycle of high CPU usage. That was sort of a red herring in my initial descriptions of testing. Just type a single letter, select it, then un-select it with mouse or keyboard. That's all it takes to start the high CPU usage phase.
I found another GTK text editor app that causes both the high CPU usage upon selecting and then un-selecting some text, and also the Plasmashell core dump after quitting the app. Apostrophe, a Markdown editor. The Flatpak version. However Norka (also Flatpak) did not cause any symptoms at all. If Norka is still on GTK3, perhaps this is specific to GTK4 apps. I wouldn't be surprised. It may be worth noting that I haven't been able to replicate the issue on my Fedora 40 system, which also has Plasma 6.1.1. The only obvious difference in the "About" page is that Tumbleweed has Qt 6.7.2 while the Fedora system has Qt 6.7.1. Both are running LTS kernel 6.6.36, not that that should be relevant. Peculiar that the Fedora system seems to be immune to this.
I did a system update on Tumbleweed and rebooted, then happened to log into the X11 session and noticed I couldn't replicate the high CPU usage bug or the Plasmashell core dump. But I did have a remarkably difficult time trying to log out of the X11 session, twice. Black screen and cursor, and couldn't even log in on other TTYs. Had to go to a TTY and then press Ctrl+Alt+Del to restart each time. That's never happened before that I can recall. So I'm not sure if something bad still happens in the X11 session after running the same test, but the symptoms were not the same. The problem logging out could be unrelated.
It should come as no surprise that after Tumbleweed updated to Plasma 6.1.2, I can still replicate the symptoms of this. Elevated CPU usage upon de-selecting any amount of selected text, then the Plasmashell core dump after quitting the GTK app.
I cannot reproduce it on openSUSE TW with KDE Plasma 6.1.2 Wayland with the Gnome Text Editor 46.3
(In reply to postix from comment #14) > I cannot reproduce it on openSUSE TW with KDE Plasma 6.1.2 Wayland with the > Gnome Text Editor 46.3 I did a `zypper dup` to be sure I'm up to date. Still able to reproduce every time, and the GNOME Text Editor version was 46.3 both before and after. But KDE Frameworks updated to 6.4.0, so now `krunner` is stuck at a fixed size instead of adapting to the larger font size I put in `~/.config/krunnerrc`. I got to enjoy a larger `krunner` dialog from a 5-year-old Reddit post trick for two whole days before it stopped working. Unrelated, of course.
Bad news. Or a clue? I was able to replicate this issue for the first time on a Fedora 40 system. Fully updated as of today, Plasma 6.1.2, Frameworks 6.3.0, Qt 6.7.2, kernel 6.6.39 (LTS). Interestingly, it is a quad-core system like the iMac12,2 with Tumbleweed that is also vulnerable to this. 8GB of RAM, it's a mini PC with a Celeron J4125 that I just set up a few days ago as a media PC. Mesa Intel UHD Graphics 600. The Fedora 40 system that still does not seem to react to this issue is a 4c/8t Ryzen 3700u Acer laptop. With 32GB of RAM. The symptoms are the same on the Fedora mini PC. High CPU usage at the same very specific level that is obviously hitting some kind of natural limiter (like a full core with plasmashell and kwin_wayland using the same core, which seems to be the case when looking at the per-core activity in btop). And then if the CPU activity is high when quitting the GTK app, plasmashell dumps core.
Something has changed after a Tumbleweed update, even though none of the Plasma/Qt version info in "About" has changed. It used to be Plasmashell using about 17% CPU, with kwin_wayland using about 15%, and Plasmashell would pretty consistently crash if it was busy when quitting the GTK app (GNOME Text Editor or Apostrophe). But now it's Plasmashell using about 21% and xdg-document-portal using about 13%. There's still some activity with kwin_wayland, but only 4-5%. And Plasmashell doesn't seem to want to crash or core dump anymore. The high CPU usage can still be triggered and stopped repeatedly by just un-selecting some text, and selecting some new text.
I cant reprdouce this on master. I suspect its fixed by https://invent.kde.org/frameworks/kguiaddons/-/commit/0420025cc0d706856076bb71143c04f857871ac2 and/or https://invent.kde.org/plasma/plasma-workspace/-/commit/da06b136f645e57b79e319e34bba4f88bee54616
(In reply to David Redondo from comment #18) > I cant reprdouce this on master. I suspect its fixed by > https://invent.kde.org/frameworks/kguiaddons/-/commit/ > 0420025cc0d706856076bb71143c04f857871ac2 and/or > https://invent.kde.org/plasma/plasma-workspace/-/commit/ > da06b136f645e57b79e319e34bba4f88bee54616 Just curious, was your test machine a quad-core? I had two different distros show the behavior on two different quad-core machines, but my 4-core/8-thread laptop with Fedora seems immune. It is not any more updated than the Fedora and Tumbleweed machines that are displaying the bug symptoms. BTW, that differing behavior I described in the most recent comment actually went away right after that, and it went back to being a plasmashell/kwin_wayland fight over a single core, just like before.
I have those commits locally and can still reproduce it with today's git master as well; re-opening. Other potentially notable information: - Wayland, of course - Everything KDE built from source on top of Qt 6.7.1 - Default Klipper settings in Plasma - gnome-text-editor installed from distro repos, no sandboxing involved - gnome-text-editor is version 46.3 - gtk from system repos is 4.14.4
Fix in progress with https://invent.kde.org/plasma/kwin/-/merge_requests/6156.
Fixed by David Edmundson with https://invent.kde.org/plasma/kwin/-/commit/6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7 in Plasma 6.2.0.
(In reply to Nate Graham from comment #22) > Fixed by David Edmundson with > https://invent.kde.org/plasma/kwin/-/commit/ > 6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7 in Plasma 6.2.0. Thanks for taking the time to confirm it and see it through, Nate. I won't see the fix in the wild for a few months, but it looks good to me, logic-wise.
(In reply to Nate Graham from comment #22) > Fixed by David Edmundson with > https://invent.kde.org/plasma/kwin/-/commit/ > 6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7 in Plasma 6.2.0. Hey, I'm a little confused here, because I thought this fix wasn't going to show up until 6.2.0, but now I can't replicate the issue on either Tumbleweed or Fedora 40 after the 6.1.4 update. Both of the quad-core systems that were affected are now acting like they are immune, like the 4c/8t Ryzen laptop with Fedora 40 that never demonstrated the issue. I'm performing all the same actions, but seeing no increased CPU usage or plasmashell core dump on the previously affected systems. If this fix isn't actually out yet, that would have to imply that the race-condition-like issue has been fixed by some other unknown patch between 6.1.3 and 6.1.4. Unless this fix was also included in 6.1.4. But there was always that thing about the 4c/8t system not being affected, which never made much sense if the issue was directly caused by the lack of checking in the clipboard code that gets fixed by this patch. It should have also been affecting the 4c/8t Ryzen system just as much as the others.
Looks like it ended up backported after all, in https://invent.kde.org/plasma/kwin/-/commit/6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7! So that explains it.
(In reply to Nate Graham from comment #25) > Looks like it ended up backported after all, in > https://invent.kde.org/plasma/kwin/-/commit/ > 6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7! So that explains it. OK, things make a bit more sense. Nice to see that it's in there already. I'll let someone else worry about the explanation for the anomaly of the 4c/8t system never being affected by the issue. Thanks, Nate.