Bug 454379

Using the above method, i am able to reproduce with file of any size.

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.

(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.

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)

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.

(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.

*** Bug 451631 has been marked as a duplicate of this bug. ***

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.

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.

Found another way to reproduce:

1) Open Gwenview
2) Open any image
3) Right Click on the image and Copy
4) Close Gwenview

Can reproduce with those steps.

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

*** Bug 451840 has been marked as a duplicate of this bug. ***

*** Bug 459087 has been marked as a duplicate of this bug. ***

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.

(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

(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.

I can still reproduce with Neon Unstable with updates as of Sep. 14th.

Never mind I can still reproduce it with Dolphin. I was trying to Gwenview steps, which are working for me.

(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

*** Bug 459296 has been marked as a duplicate of this bug. ***

(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

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)

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.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/80

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