When trying to move a couple of files around in Dolphin (reproduced with 10 tiny .png’s), Plasma Shell freezes, and I need to kill it. QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner QXcbClipboard::setMimeData: Cannot set X11 selection owner qml: totalCountChanged 1 qml: totalCountChanged 1 qml: totalCountChanged 0 qml: totalCountChanged 0 Currrent active notifications: QHash() Guessing partOf as: 0 New Notification: "Moving: Finished" "/home/kwpolska/Desktop/tosort/OK/00046.png" 6000 & Part of: 0 Currrent active notifications: QHash(("notification 3", "dolphinMoving: Finished")) Guessing partOf as: 3 New Notification: "Moving: Finished" "/home/kwpolska/Desktop/tosort/OK/00046.png" 6000 & Part of: 3 trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog When trying to use Dolphin’s bulk rename feature, it seems to be slowed down because thousands of notifications are generated. Reproducible: Always Steps to Reproduce: 1. Try to move a couple of small files around Actual Results: Plasma Shell hangs, even though the operation completes in Dolphin quickly Expected Results: No hang
Thanks for the report. Which Dolphin version is that please? Also what's your plasma-framework version? > When trying to use Dolphin’s bulk rename feature, it seems to be slowed down because thousands of notifications are generated. What do you mean by that? Are there thousands of notification popups?
One other thing that you could do is attach gdb to the frozen plasmashell and get the backtrace, that would show us exactly where it is stuck in. If you don't know gdb, just follow these steps: 1) install plasma-framework and plasma-workspace debug packages 2) install gdb 3) copy the files and make plasmashell frozen 4) open Konsole and type "sudo gdb --pid `pidof plasmashell`" 5) wait a bit 6) type "thread apply all bt" 7) save the output and attach here That would help.
> Which Dolphin version is that please? Also what's your plasma-framework version? Dolphin 15.08.0, plasmashell 5.4.0 >> When trying to use Dolphin’s bulk rename feature, it seems to be slowed down because thousands of notifications are generated. > What do you mean by that? Are there thousands of notification popups? When plasmashell catches up, the notification number is high. Also, it consumes huge amounts of CPU time. For example, I tried with 160 items. Dolphin was quick to show the rename happened, but Plasma Shell froze, and then displayed a notification number in the 120s, then going to zero.
Ok, I've just tried the mass rename in Dolphin and I'm getting no notification whatsoever, tried with hundreds of files. What does the rename notification say? I'll try searching all the code for that. As a side note, Dolphin itself has a single notification and that's for emptying the trash, which leads me to believe that this is the notification "[Finished] Rename", which would appear only when the renaming is taking longer than certain time.
It’s actually a Moved notification.
Ok. The gdb output would still be very much useful.
That’s harder to get, I would have to recompile everything, because Arch can’t be arsed to provide debug packages. And I can’t be arsed to recompile them.
Well then I can't really be arsed to help out :P It should enough to get just plasma-framework fwiw.
Created attachment 94355 [details] traceback I attached a traceback, is it helpful enough? I rebuilt plasma-workspace and plasma-framework with debug symbols.
It's not ideal but it does help understanding what's up, thanks. Basically, if you mass rename things and it takes some time (like on slower disks), Plasma will create one job+notification for each file being renamed. Adding hundreds of things in about one second will just make it slow down. I'm not sure where this should be fixed though, I would say Dolphin and/or KIO should treat the mass rename as a single operation, though I'm not sure about it's internals. I'll think about what we can do from Plasma's side.
Here are steps for reproducing 1) $ yes > y.log 2) stop after a second or two 3) $ for i in {1..1000}; do touch test$i.txt; cat ~/y.log > test$i.txt; done 4) open Dolphin, select all those files and hit f2 5) set it to "testtest#.txt" 6) watch plasma freeze
I am also sometimes experiencing freezes during file operations - unfortunately, not reproducible. In one case just now, the entire file job seems to have crashed - the notification would not go away, the Dolphin window that started it acted all weird (e.g., it was on top of all the popups Plasma opened), and I had to kill plasmashell and restart it to get rid of the notification. Hopefully, next time it freezes, I can catch a backtrace. But that's hard to do, with it only randomly freezing for a couple of seconds. I tried the mass-rename, which is very slow (it seems to take almost a minute), but Plasma doesn't freeze.
Created attachment 94635 [details] gdb bacjtrace from frozen plasma Plasma froze again, and I attached gdb to it as quickly as I could and got this backtrace. I'm not entirely surprised to see clipbaord stuff here again, that one was already responsible for Plasma freezes ever since I use KDE4.
Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=358231? There's a patch proposal for that specific bug ticket.^
@Ralf there's something interesting in that backtrace that I hadn't realised. #17 0x00007ffff19744ea in QClipboard::dataChanged() which is fair enough then we get #10 0x00007ffff5747925 in QQuickTextEdit::q_canPasteChanged() (this=0x555556027b30) before the blocking #0 0x00007fffe7398dc8 in QXcbClipboard::waitForClipboardEvent but it means we load the clipboard data (in a blocking way!) for every single QQuickTextEdit. Plasma has a lot of text fields which is why the slightly slow clipboard event stacks up rapidly into a problem.
Files updating the clipboard comes from KIO::clipboardUpdater which updates after every file. Which probably wouldn't be too bad, if Plasma didn't have the bug above.
Thank you for the report. As this was reported on an older version of plasmashell, can you please test on a recent and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.
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!