https://bugs.kde.org/show_bug.cgi?id=489644
--- Comment #5 from RedBearAK <redb...@redbearnet.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
