Bug 454379 - After any file is copied from Dolphin and Dolphin is closed, Plasma panel widgets have a delay before closing
Summary: After any file is copied from Dolphin and Dolphin is closed, Plasma panel wid...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard (show other bugs)
Version: 5.26.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: wayland
: 451631 451840 459087 459296 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-05-25 08:06 UTC by Bacteria
Modified: 2022-12-25 19:28 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.102


Attachments
Plasma slowing down after copying ISO file and when the clipboard is cleared, plasma starts working normally (2.20 MB, video/x-matroska)
2022-05-25 08:06 UTC, Bacteria
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bacteria 2022-05-25 08:06:23 UTC
Created attachment 149196 [details]
Plasma slowing down after copying ISO file and when the clipboard is cleared, plasma starts working normally

SUMMARY
When large files like videos, ISOs are copied, plasmashell becomes slow to respond after some time.

It is important to note that other than plasmashell, applications continue to work normally.

STEPS TO REPRODUCE
1. Enable clipboard in plasma settings 
2. Open dolphin
3. Copy large files like an OS ISOs or movie files
4. Close dolphin 
5. Launch Kickoff, system tray

OBSERVED RESULT
Plasmashell becomes slow to respond and animations become slower.

EXPECTED RESULT
Plasmashell should continue to work normally.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.24.90
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Graphics Platform: Wayland


ADDITIONAL INFORMATION
Ways to fix the slowed down plasmashell:
1. Clear the clipboard
2. Copy a small file or text
Comment 1 Bacteria 2022-05-26 03:07:07 UTC
Using the above method, i am able to reproduce with file of any size.
Comment 2 John 2022-05-26 11:45:42 UTC
For me, using Kubuntu 21.10 on a BTRFS+Zstd partition and latest KDE Plasma from Kubuntu's backports PPA, I've seen KDE Plasma many times becoming very slow and even unresponsive to the point that everything freezes with heavy IO operations like copying many folders and files or extracting archives.
Comment 3 Bacteria 2022-05-26 17:23:43 UTC
(In reply to John from comment #2)
> For me, using Kubuntu 21.10 on a BTRFS+Zstd partition and latest KDE Plasma
> from Kubuntu's backports PPA, I've seen KDE Plasma many times becoming very
> slow and even unresponsive to the point that everything freezes with heavy
> IO operations like copying many folders and files or extracting archives.

I think the issue you are describing is unrelated to this one as this one is closely tied to the clipboard applet and can be solved by clearing clipboard. I remember a similar issue to yours but can't find it.
Comment 4 Akseli Lahtinen 2022-06-04 21:52:31 UTC
I also have this issue, it happens only if clipboard history holds anything that is not text and I'm on wayland. It can be small or big file, as long as it's a file. It also only happens after I close dolphin.


System info:

Operating System: Fedora Linux 36
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.17.11-300.fc36.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 15,6 GiB of RAM
Graphics Processor: AMD DIMGREY_CAVEFISH (RX 6600)
Comment 5 Firlaev-Hans 2022-08-05 09:33:12 UTC
Could this be a duplicate of Bug 451631 ?
In that bug report I discovered that essentially the same thing happens not when closing dolphin but rather after restarting plasmashell (including by just rebooting or logging out and back in) when the top most item in the clipboard is a file. But I can confirm that closing dolphin instead of restarting Plasma produces the same results.
Clearing the clipboard or copying text makes plasmashell responsive again in either case.

Every time a slowdown happens, the following lines appear in the journal:
>plasmashell[1756]: QWaylandDataOffer: timeout reading from pipe
>plasmashell[1756]: QWaylandDataOffer: error reading data for mimeType application/x-kde-cutselection


But regarding what John described
>For me, using Kubuntu 21.10 on a BTRFS+Zstd partition and latest KDE Plasma from Kubuntu's backports PPA,
>I've seen KDE Plasma many times becoming very slow and even unresponsive to the point that everything freezes
>with heavy IO operations like copying many folders and files or extracting archives.
I believe that is a different issue. I encountered that at some point as well when I copied hundreds of gigabytes to an external HDD, but I think that's some KIO issue that causes a total freeze, rather than this issue which seems to be the clipboards fault and only causes brief slowdowns.
Comment 6 Bacteria 2022-08-05 09:40:40 UTC

(In reply to Firlaev-Hans from comment #5)
> Could this be a duplicate of Bug 451631 ?
> In that bug report I discovered that essentially the same thing happens not
> when closing dolphin but rather after restarting plasmashell (including by
> just rebooting or logging out and back in) when the top most item in the
> clipboard is a file. But I can confirm that closing dolphin instead of
> restarting Plasma produces the same results.
> Clearing the clipboard or copying text makes plasmashell responsive again in
> either case.
> 
> Every time a slowdown happens, the following lines appear in the journal:
> >plasmashell[1756]: QWaylandDataOffer: timeout reading from pipe
> >plasmashell[1756]: QWaylandDataOffer: error reading data for mimeType application/x-kde-cutselection
> 
> 
> But regarding what John described
> >For me, using Kubuntu 21.10 on a BTRFS+Zstd partition and latest KDE Plasma from Kubuntu's backports PPA,
> >I've seen KDE Plasma many times becoming very slow and even unresponsive to the point that everything freezes
> >with heavy IO operations like copying many folders and files or extracting archives.
> I believe that is a different issue. I encountered that at some point as
> well when I copied hundreds of gigabytes to an external HDD, but I think
> that's some KIO issue that causes a total freeze, rather than this issue
> which seems to be the clipboards fault and only causes brief slowdowns.

Indeed, bug 451631 looks like a duplicate. I will mark that one as duplicate of this one because of more consistent reproducing instructions.
Comment 7 Bacteria 2022-08-05 09:41:44 UTC
*** Bug 451631 has been marked as a duplicate of this bug. ***
Comment 8 guimarcalsilva 2022-08-18 20:33:23 UTC
I was about to make a bug report but I found this. I can confirm this happens. Clearing the clipboard history in the widget seems to speed things up again. Also, this happens on a fresh boot if you have any files copied to the clipboard.
Comment 9 guimarcalsilva 2022-08-18 20:33:28 UTC
I was about to make a bug report but I found this. I can confirm this happens. Clearing the clipboard history in the widget seems to speed things up again. Also, this happens on a fresh boot if you have any files copied to the clipboard.
Comment 10 Bacteria 2022-08-25 05:00:42 UTC
Found another way to reproduce:

1) Open Gwenview
2) Open any image
3) Right Click on the image and Copy
4) Close Gwenview
Comment 11 Nate Graham 2022-08-25 05:02:58 UTC
Can reproduce with those steps.
Comment 12 Bacteria 2022-08-25 09:00:38 UTC
I was exploring debuginfod on Arch and decided to get backtrace for this particular case. Opened Gwenview, copied file and closed it. Then tried to launch KickOff and gdb stopped and said "plasmashell" received SIGPIPE. And i got this backtrace: https://pastebin.com/cyEdHnv7

Not sure if it can help.  But posting it here anyway
Comment 13 Nate Graham 2022-09-01 14:24:43 UTC
*** Bug 451840 has been marked as a duplicate of this bug. ***
Comment 14 Bacteria 2022-09-14 11:44:26 UTC
*** Bug 459087 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2022-09-14 15:35:02 UTC
I could reproduce this issue last month, but I can't anymore with the current state of git master. Can anyone else? It might have been fixed recently.
Comment 16 Bucior 2022-09-14 16:07:31 UTC
(In reply to Nate Graham from comment #15)
> I could reproduce this issue last month, but I can't anymore with the
> current state of git master. Can anyone else? It might have been fixed
> recently.

I can reproduce on lastest archlinux. I will check again when 5.26 reaches beta

Operating System: Arch Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.8-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD Radeon RX 6800 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X570S AORUS ELITE AX
System Version: -CF
Comment 17 Firlaev-Hans 2022-09-14 16:37:56 UTC
(In reply to Nate Graham from comment #15)
> I could reproduce this issue last month, but I can't anymore with the
> current state of git master. Can anyone else? It might have been fixed
> recently.

Still reproducible latest Neon Unstable, so if it was in fact fixed it must have been VERY recently (i. e. ~ this week) if the fix hasn't even made it to Neon unstable yet.
Comment 18 guimarcalsilva 2022-09-15 03:03:53 UTC
I can still reproduce with Neon Unstable with updates as of Sep. 14th.
Comment 19 Nate Graham 2022-09-15 16:18:05 UTC
Never mind I can still reproduce it with Dolphin. I was trying to Gwenview steps, which are working for me.
Comment 20 imaginator 2022-09-30 13:51:13 UTC
(In reply to Nate Graham from comment #15)
> I could reproduce this issue last month, but I can't anymore with the
> current state of git master. Can anyone else? It might have been fixed
> recently.
FWIW: I can't reproduce this. Neither with a ~400 MB .iso copied in Dolphin nor with a 10 MB raw-foto in Gwenview. System is snappy as it was before although both files are still in the clipboard.

I have Xwayland installed, though. Could this matter here?

--
Operating System: Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.19.12 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics
Comment 21 Nate Graham 2022-10-31 18:10:52 UTC
*** Bug 459296 has been marked as a duplicate of this bug. ***
Comment 22 Akseli Lahtinen 2022-11-25 19:06:47 UTC
(In reply to Nate Graham from comment #15)
> I could reproduce this issue last month, but I can't anymore with the
> current state of git master. Can anyone else? It might have been fixed
> recently.

I can still reproduce the issue

Operating System: Fedora Linux 37
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 6.0.9-300.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 15,5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600
Comment 23 Fabian Vogt 2022-11-25 23:08:57 UTC
I had a quick look. Turns out I never hit this issue because the clipboard history doesn't always work here, I had to restart plasmashell.

tl;dr: When dolphin quits, Plasma takes ownership of the selection. When it gets focus it doesn't remember and asks itself (through wayland) about its content -> deadlock.

Using WAYLAND_DEBUG=1, I the issue is visible:

When dolphin exits, the selection is cleared. plasmashell is notified about that:

[2622585.375] zwlr_data_control_device_v1@116.selection(nil)
[2622585.384]  -> zwlr_data_control_offer_v1@4278190091.destroy()

And subsequently takes ownership of the selection:

[2622585.434]  -> zwlr_data_control_manager_v1@115.create_data_source(new id zwlr_data_control_source_v1@207)
[2622585.447]  -> zwlr_data_control_source_v1@207.offer("text/uri-list")
[2622585.453]  -> zwlr_data_control_source_v1@207.offer("application/x-kio-metadata")
[2622585.459]  -> zwlr_data_control_source_v1@207.offer("application/x-kde-cutselection")
[2622585.464]  -> zwlr_data_control_source_v1@207.offer("application/x-kde-onlyReplaceEmpty")
[2622585.472]  -> zwlr_data_control_source_v1@207.offer("text/plain;charset=utf-8")
[2622585.481]  -> zwlr_data_control_device_v1@116.set_selection(zwlr_data_control_source_v1@207)
[2622585.548]  -> org_kde_plasma_window@157.destroy()
[2622586.048]  -> org_kde_plasma_window@144.destroy()
[2622586.080]  -> org_kde_plasma_window@211.destroy()

Plasmashell is then notified about its own change (which is a bit weird but so far ok):
[2622586.111] zwlr_data_control_device_v1@116.data_offer(new id zwlr_data_control_offer_v1@4278190091)
[2622586.121] zwlr_data_control_offer_v1@4278190091.offer("text/uri-list")
[2622586.128] zwlr_data_control_offer_v1@4278190091.offer("application/x-kio-metadata")
[2622586.134] zwlr_data_control_offer_v1@4278190091.offer("application/x-kde-cutselection")
[2622586.139] zwlr_data_control_offer_v1@4278190091.offer("application/x-kde-onlyReplaceEmpty")
[2622586.144] zwlr_data_control_offer_v1@4278190091.offer("text/plain;charset=utf-8")
[2622586.151] zwlr_data_control_device_v1@116.selection(zwlr_data_control_offer_v1@4278190091)
[2622587.436] wl_display@1.delete_id(157)
[2622587.447] wl_display@1.delete_id(144)
[2622587.450] wl_display@1.delete_id(211)
[2622587.458] zwlr_data_control_source_v1@207.send("text/uri-list", fd 39)

The issue starts when plasmashell gains keyboard focus:

[2633917.635] wl_keyboard@3.enter(3533, wl_surface@211, array[0])
[2633917.652]  -> wl_display@1.sync(new id wl_callback@160)
[2633917.659] wl_keyboard@3.modifiers(3528, 0, 0, 0, 0)

At that point the plain wayland selection protocol announces its contents (currently held by plasmashell itself):

[2633917.669] wl_data_device@10.data_offer(new id wl_data_offer@4278190092)
[2633917.678] wl_data_offer@4278190092.offer("text/uri-list")
[2633917.685] wl_data_offer@4278190092.offer("application/x-kio-metadata")
[2633917.691] wl_data_offer@4278190092.offer("application/x-kde-cutselection")
[2633917.697] wl_data_offer@4278190092.offer("application/x-kde-onlyReplaceEmpty")
[2633917.702] wl_data_offer@4278190092.offer("text/plain;charset=utf-8")
[2633917.708] wl_data_offer@4278190092.source_actions(0)
[2633917.713] wl_data_device@10.selection(wl_data_offer@4278190092)

Plasma is immediately interested in its "application/x-kde-cutselection" content and asks for it:
#0  0x00007ffff511c470 in QtWayland::wl_data_offer::receive(QString const&, int)@plt () at /lib64/libQt5WaylandClient.so.5
#1  0x00007ffff514d0b4 in  () at /lib64/libQt5WaylandClient.so.5
#2  0x00007ffff5f99584 in QInternalMimeData::retrieveData(QString const&, QVariant::Type) const () at /lib64/libQt5Gui.so.5
#3  0x00007ffff5b01520 in  () at /lib64/libQt5Core.so.5
#4  0x00007ffff5b024dd in QMimeData::data(QString const&) const () at /lib64/libQt5Core.so.5
#5  0x00007ffff4ea5ff1 in KIO::isClipboardDataCut(QMimeData const*) (mimeData=mimeData@entry=0x555559b865d0) at /usr/src/debug/kio-5.100.0/src/widgets/paste.cpp:360
#6  0x00007ffff073b9bf in KFilePreviewGeneratorPrivate::applyCutItemEffect(KFileItemList const&) (this=this@entry=0x55555641e8e0, items=...) at /usr/src/debug/kio-5.100.0/src/filewidgets/kfilepreviewgenerator.cpp:871
#7  0x00007ffff073d327 in KFilePreviewGeneratorPrivate::updateCutItems() (this=0x55555641e8e0) at /usr/src/debug/kio-5.100.0/src/filewidgets/kfilepreviewgenerator.cpp:684
[...]
#13 0x00007ffff5f89b1d in QClipboard::emitChanged(QClipboard::Mode) () at /lib64/libQt5Gui.so.5

[2633917.886]  -> wl_data_offer@4278190092.receive("application/x-kde-cutselection", fd 43)

This is a deadllock: Plasmashell is asking for its own selection content. Timeout to the rescue!

QWaylandDataOffer: timeout reading from pipe
QWaylandDataOffer: error reading data for mimeType application/x-kde-cutselection

After the timeout the event processing resumes:

[2634919.439] zwp_primary_selection_device_v1@12.data_offer(new id zwp_primary_selection_offer_v1@4278190093)
[2634919.464] zwp_primary_selection_offer_v1@4278190093.offer("text/plain")
[2634919.473] zwp_primary_selection_offer_v1@4278190093.offer("text/plain;charset=utf-8")
[2634919.482] zwp_primary_selection_offer_v1@4278190093.offer("STRING")
[2634919.490] zwp_primary_selection_offer_v1@4278190093.offer("text/plain")
[2634919.497] zwp_primary_selection_offer_v1@4278190093.offer("text/html")
[2634919.504] zwp_primary_selection_offer_v1@4278190093.offer("TARGETS")
[2634919.515] zwp_primary_selection_offer_v1@4278190093.offer("MULTIPLE")
[2634919.525] zwp_primary_selection_offer_v1@4278190093.offer("TIMESTAMP")
[2634919.534] zwp_primary_selection_offer_v1@4278190093.offer("SAVE_TARGETS")
[2634919.544] zwp_primary_selection_device_v1@12.selection(zwp_primary_selection_offer_v1@4278190093)
[2634919.558] zwp_text_input_v2@21.enter(3534, wl_surface@211)
[2634919.571] xdg_toplevel@157.configure(685, 516, array[4])
[2634919.585] xdg_surface@144.configure(3535)
[2634919.616] wl_buffer@185.release()
[2634919.625] wl_buffer@203.release()
[2634919.632] wl_buffer@206.release()
[2634919.640] wl_callback@160.done(3535)

Eventually plasmashell gets the request sent from plasmashell in the past:
[2634919.657] zwlr_data_control_source_v1@207.send("application/x-kde-cutselection", fd 41)
Comment 24 David Redondo 2022-12-02 07:47:44 UTC
This will be a general problem whenever something is pasted from klipper DataControlSource to plasma itself (that is https://bugs.kde.org/show_bug.cgi?id=442521)

In this specific instance it is a bit weird that opening kickoff triggers reading the clipboard content.
Comment 25 Bug Janitor Service 2022-12-07 15:00:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/80
Comment 26 David Redondo 2022-12-08 12:23:52 UTC
Git commit 3984732e007e71632a525d89227fdfe94fa037ad by David Redondo.
Committed on 08/12/2022 at 09:54.
Pushed by davidre into branch 'master'.

waylandclipboard: Update QClipboard when gaining focus

A process that owns the clipboard via KSystemClipboard (wlr-data-control)
and tries to read the clipboard via QClipboard  will deadlock itself and
eventually times out because the read is done blocking and the send event
is only received afterwards by WaylandClipboard.
When Qt knows it owns the keyboard it can get the data directly, so the
idea is to set QClipboard if possible. However this can be done only
when the Application has focus. Unfortunately inside Qt window system events
are delieverd asnycronously while QClipboard uses signal to indicate changes,
this makes QGuiApplication::focusWindowChanged not useable here because it
happens to late - after the QClipboard signal. For this reason we bind
to the wl_seat and track focus ourselves.
QClipboard takes ownership of QMimeData that is passed into it and so does
KSystemClipboard and ultimately DataControlSource which now uses unique_ptr
to signify this and make it clear that ownership is transferred when the
QClipboard is set.
Related: bug 442521

M  +5    -0    src/CMakeLists.txt
M  +106  -4    src/systemclipboard/waylandclipboard.cpp
M  +3    -0    src/systemclipboard/waylandclipboard_p.h

https://invent.kde.org/frameworks/kguiaddons/commit/3984732e007e71632a525d89227fdfe94fa037ad