Bug 351897 - Plasma Shell freezes/hangs on file operations
Summary: Plasma Shell freezes/hangs on file operations
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.4.0
Platform: Arch Linux Linux
: NOR crash
Target Milestone: 1.0
Assignee: Martin Klapetek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-28 13:33 UTC by Chris Warrick
Modified: 2020-12-22 23:06 UTC (History)
15 users (show)

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


Attachments
traceback (15.79 KB, text/plain)
2015-09-02 18:25 UTC, Chris Warrick
Details
gdb bacjtrace from frozen plasma (16.63 KB, text/plain)
2015-09-18 15:53 UTC, Ralf Jung
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Warrick 2015-08-28 13:33:52 UTC
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
Comment 1 Martin Klapetek 2015-09-02 15:05:30 UTC
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?
Comment 2 Martin Klapetek 2015-09-02 15:07:57 UTC
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.
Comment 3 Chris Warrick 2015-09-02 15:24:13 UTC
> 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.
Comment 4 Martin Klapetek 2015-09-02 16:25:28 UTC
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.
Comment 5 Chris Warrick 2015-09-02 16:27:23 UTC
It’s actually a Moved notification.
Comment 6 Martin Klapetek 2015-09-02 16:34:58 UTC
Ok. The gdb output would still be very much useful.
Comment 7 Chris Warrick 2015-09-02 17:20:38 UTC
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.
Comment 8 Martin Klapetek 2015-09-02 17:26:15 UTC
Well then I can't really be arsed to help out :P

It should enough to get just plasma-framework fwiw.
Comment 9 Chris Warrick 2015-09-02 18:25:48 UTC
Created attachment 94355 [details]
traceback

I attached a traceback, is it helpful enough? I rebuilt plasma-workspace and plasma-framework with debug symbols.
Comment 10 Martin Klapetek 2015-09-02 18:34:42 UTC
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.
Comment 11 Martin Klapetek 2015-09-02 18:43:25 UTC
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
Comment 12 Ralf Jung 2015-09-15 16:03:49 UTC
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.
Comment 13 Ralf Jung 2015-09-18 15:53:40 UTC
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.
Comment 14 Pekka Helenius 2018-02-23 00:06:12 UTC
Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=358231?

There's a patch proposal for that specific bug ticket.^
Comment 15 David Edmundson 2018-07-17 17:14:24 UTC
@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.
Comment 16 David Edmundson 2018-08-17 13:04:07 UTC
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.
Comment 17 Justin Zobel 2020-12-06 21:16:23 UTC
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.
Comment 18 Bug Janitor Service 2020-12-21 04:34:27 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!