Bug 511672

Thanks for the bug report. So we can start trying to determine what's happening, I'd like to ask you for some information.

- If you could attach an image that causes this freeze to this report, that would be very helpful.
- Can you check kwin's logs when the temporary freeze occurs? 

  journalctl --boot --user-unit plasma-kwin_wayland > ~/log.txt

Thanks.

Created attachment 186546 [details]
Image as example for hang

When running the asked command, the terminal outputs this:

Hint: You are currently not seeing messages from the system.
      Users in groups 'adm', 'systemd-journal', 'wheel' can see all messages.
      Pass -q to turn off this notice.

The asked log.txt content. It is the same before, during and after hang. It is after a cold boot, navigating thru Dolphin to the image, opening it in Gwenview an copying it with Ctrl+C.

nov 06 17:09:02 rosa-fx1umn systemd[1251]: Starting KDE Window Manager...
nov 06 17:09:02 rosa-fx1umn systemd[1251]: Started KDE Window Manager.
nov 06 17:09:02 rosa-fx1umn kwin_wayland[1439]: No backend specified, automatically choosing drm
nov 06 17:09:03 rosa-fx1umn kwin_wayland[1439]: kwin_xkbcommon: XKB: Multiple definitions of group 1 name in map 'basic'; Using 'Romanian', ignoring 'English (US)'
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1531]: The XKEYBOARD keymap compiler (xkbcomp) reports:
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1531]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1531]: > Warning:          Could not resolve keysym XF86Accessibility
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1531]: > Warning:          Could not resolve keysym XF86DoNotDisturb
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1531]: Errors from xkbcomp are not fatal to the X server
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: The XKEYBOARD keymap compiler (xkbcomp) reports:
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: > Warning:          Unsupported maximum keycode 708, clipping.
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: >                   X11 cannot support keycodes above 255.
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: > Warning:          Virtual modifier ScrollLock multiply defined
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: >                   Using 0, ignoring 0
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: > Warning:          Could not resolve keysym XF86Accessibility
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: > Warning:          Could not resolve keysym XF86DoNotDisturb
nov 06 17:09:03 rosa-fx1umn kwin_wayland_wrapper[1538]: Errors from xkbcomp are not fatal to the X server
nov 06 17:09:28 rosa-fx1umn kwin_wayland[1439]: Module 'org.kde.kwin.decoration' does not contain a module identifier directive - it cannot be protected from external registrations.

Thanks for the logs, and for attaching the graphic.
I'm not able to reproduce this on git-master using that graphic and the steps you outlined,
nor am I able to reproduce on Fedora 43 with Plasma 6.5.2

1. Open the attached image in Gwenview
2. Ctrl+C to copy just this image
3. Click on the clipboard applet in the panel

I wanted to clarify something. You said
> I observed it with gwenview only, when the clipboard is set up to copy only text.

I don't see an option in the clipboard to copy only text. In clipboard settings - General Configuration I see
> Non-text selection - Always save in history / Only when explicitly copied / Never save in history

I set this to Never save in history. Is that the setting you were referring to?

Main problem of this bug report:
The hang-up problem I observed it only with Gwenview in relation with the Clipboard Manager, no matter what option is choosen. If the Clipboard Manager is completely disabled, there is no problem.
UPDATE: testing MxLinux 25 with plasma 6.3.6, on the iso qimgv is the default viewer instead of gwenview. It acts exactly in the same way as gwenview. So gwenview is not the only app acting alike. Tested qimgv on the Opensuse Tumbleweed too, it confirms that to me.

So for the moment only Nomacs works with Clipboard Manager as intended.

A secondary problem regards Non-text selection’s options. It is not the subject of this hang-up bug report, but I think it has to be addressed too, if it has not been reported already:
No matter which option is chosen in 'Non-text selection - Only when explicitly copied / Never save in history', copying from Dolphin, Gwenview (with hang up) or Nomacs, the images are copied with thumbnails into the Clipboard Manager. Maybe I do not understand correctly, but Never save in history (with that explaining info under the option) means for me, that in this case images should NOT be copied into the Clipboard Manager.

But, in relation with Libreoffice, Clipboard Manager works somehow more correctly, because if 'Never save in history' is chosen, than image is not saved. Problem occurs when 'Only when explicitly copied' is chosen, image is somehow copied, but it generates seemingly an empty line in Clipboard Manager, without a thumbnail or text info about the content of the record, so impossible to find in clipboard history if you have multiple images copied one after the other. From this empty record the image can be copied back to a Libreoffice document, but not into gimp for example, which gives the error of not having any data to copy.

Third problem is:
Seems like Clipboard Manager do not copies any image from Gimp, Inkscape, KolourPaint for example, no mater what option I choose.

So, the second and third problems might be considered also as bugs, including the libreoffice-regarding one too. 

So, from my perspective Plasma 6 Clipboard Manager is a completely unusable piece of software. On X11 I succeeded to partially replace it, but on wayland I haven’t found a replacement for it.

Getting back to the hang-up bug and that you cannot reproduce it, it might be because different software and hardware combination, even if the whole system is the same, will react differently. But on my hardware on each distro plasma acts almost the same, just the timing is different, depending on distro and hardware used. All hardware works correctly with plasma 5 on X11, no hang up, even with very large images. Maybe try on X11 too, because there is more evident the problem, with more drastic results.

I can reproduce this on two laptops. One is a Dell Vostro 15 3530 with an 13th Gen Intel® Core™ i7-1355U, 15.3 usable RAM and a LENOVO IdeaPad Slim 5 15ARP10, AMD Ryzen 7 7735HS with 12.7 GB usable RAM, beginning from the installation iso of Rosa which runs plasma 6.3.1 on X11, then on 6.4.3 and 6.4.5 installations on X11 and Wayland too, on other kde distros running plasma 6, until the latest KDE Neon iso with plasma 6.5.1 (neon-user-20251106-0745.iso) and Opensuse Thumbleweed with 6.5.2 (openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20251106-Media.iso), both on X11 and wayland.

To test with the latest plasma 6.5.2 I made my tests on the Opensuse Tumbleweed live iso. For testing purposes I upscaled the test image and made the test on X11 too. There is more accentuated the problem, because for bigger images clipboard entry is always an empty record, or if sufficiently big, in the end gwenview will crash. What I observed, that during copying (CTRL+C) into clipboard, on X11 the processor works a lot, sometimes completely at 100% (all threads together), gwenview memory usage gets bigger and bigger, starting from around 750MB for the upscaled image until 3.7GB, and when the empty record is created remains at 2.3GB, not returning to its starting usage, as when Clipboard thumbnail is created normally. If the image is sufficiently big, it runs out of memory  and gwenview will crash. I don’t think this is normal what does gwenview or klipper generates in gwenview from a 10-20-30 MB sized images, resulting in several GB memory usage for a simple copy (CTRL+C). When klipper is completely disabled, there is no processor or memory usage increase for gwenview (UPDATE: or qimgv) when copying then pasting an image, and everything work OK.
-----------------------------------
Hang-up results on DELL, with Opensuse Tumbleweed live iso with plasma 6.5.2.

X11
test.jpg – sometime 43 sec. hang resulting an empty record in clipboard, or sometime 15 sec. hang with normal record in clipboard.
test-upscaled.jpg – 1 min. 40 sec. hang – always an empty record in clipboard
If the clipboard is not empty, trying to click on it during the hangup, at the end of it might result in a longtime, maybe complete freeze of panel. I had no patience to wait plus than 5 minutes to see if it recovers or not.

Wayland
test.jpg – 5 sec. hang – normal record in clipboard
test-upscaled.jpg – no hang – normal record in clipboard

Curious, why on Wayland it hangs for the smaller image and not for the bigger one. It happens the same on all tests.. X11 at least acts more logically.

-----------------------------------
Hang-up results on Lenovo, with Opensuse Tumbleweed live iso with plasma 6.5.2

X11
test.jpg – 28 sec. hang – normal record in clipboard
test-upscaled.jpg – 1 min. 45 sec. hang – empty record in clipboard

Wayland
test.jpg – 7 sec. hang – normal record in clipboard
test-upscaled.jpg – 1 sec. hang – normal record in clipboard

-----------------------------------
Hang-up results on Lenovo, with Rosa Desctop Fresh 13 intallation with plasma 6.4.5

Wayland
test.jpg – 14 sec. hang – normal record in clipboard
test-upscaled.jpg – 2 sec. hang – normal record in clipboard


The original and upscaled test images and some screenshots I uploaded here: https://mega.nz/folder/AJBRxKqY#3I5lc1KQqtnO9lKhPyxVHA

(In reply to erfan from comment #5)

Thanks for the additional details, that's helpful.

> Main problem of this bug report:
> The hang-up problem I observed it only with Gwenview in relation with the
> Clipboard Manager, no matter what option is choosen. If the Clipboard
> Manager is completely disabled, there is no problem.
> UPDATE: testing MxLinux 25 with plasma 6.3.6, on the iso qimgv is the
> default viewer instead of gwenview. It acts exactly in the same way as
> gwenview. So gwenview is not the only app acting alike. Tested qimgv on the
> Opensuse Tumbleweed too, it confirms that to me.

This does point to the clipboard being the problem, rather than a specific app. I'll see if I can reproduce this, given the other testing details you provided. Thanks for your diligent and thorough troubleshooting.

> A secondary problem regards Non-text selection’s options. It is not the
> subject of this hang-up bug report, but I think it has to be addressed too

In order for things to be actionable, we require that there be only one issue per report. Please open a new report for that issue.

> Third problem is:
> Seems like Clipboard Manager do not copies any image from Gimp, Inkscape,
> KolourPaint for example, no mater what option I choose.

This also should be reported in a separate bug report.

I found this is the same bug as bug 490952 - the common factor is copying a large image causes a hang.

*** This bug has been marked as a duplicate of bug 490952 ***

On the Rosa forum, before posting the bug report I was directed to this Firefox&Nimbus related bug, but from my point of view, this is not the same. That might be the same with the secondary and third problems mentioned here. I will try to justify it why.

In order to report secondary and third problems bug, investigating what is Libreoffice, Firefox, Gimp and Inkscape relation with Klipper, I concluded, that the bug which is related to Gwenview or Qimgv might not be the same.

On my Rosa installation, on the Lenovo laptop, Libreoffice, Firefox, Gimp and Inkscape, when Only when explicitly copied option is selected, all has a hang up, when trying to copy a bigger image. Libreoffice, Firefox and Gimp after a hangup in the clipboard there is just an empty line on which if QRcode can be generated, it writes out a -1x-1. Sometimes this text appears in clipboard history too.

When Never save in history is choosed, then Libreoffice, Firefox and Gimp works correctly, Inkscape not.

In both cases Klipper saves from Inkscape not an image but a huge textfile, which proves to be in fact an .svg, because if I succeed (because it finally crashed – or the texteditor, or plasmashell runs out of memory) to copy the text into the texteditor (kwrite) and save it as .svg, imageviewers opens it correctly.

Searching on web some infos regarding this, pointed me to check what is inside ~/.local/share/klipper/data/. It doesn’t come to my mind before, to check the records here, but good point regarding the Gwenview and Qimgv problems too.

What I discovered is, that whenever Klipper succeeds to create a correct record from Gwenview or Qimgv from a picture, it creates a new image inside the record’s own folder and not just the files indicating the source of the image. If the image can be created, than it will not be the a copy of the original one, but it will be a completely different one (in my case the 3.1MB sized test.jpg image was 19.1MB big PNG image). On Wayland if it cannot start to create this new image for test-upscaled.jpg, it drops quickly an empty file instead of it, and the clipboard entry seems to work correctly. That is why the hang up is way more shorter for more bigger images. 

The images from Libreoffice, Firefox, Gimp and Inkscape, including screenshots mentioned in the Nimbus related bug are in a temporary, ephemeral estate, because they are embeded infact into an .odt, .xcf, .svg file (I don’t know how Firefox handles images) so clipboard takes them ot from here an tries to save them for later use, creating a personal copy of them. (I do not know why it does not take directly the picture out from .odt because if I chose to edit the image with an external editor from within Libreoffice I can do it without problem)

So, the creation of the new file generates the hang up. That might be the same problem in all cases.

Copying large file on:

X11
New image is not generated in Klipper’s data folder over a certain image size, resulting a prolonged hangup or finally crash of the source app and unusable record is created

Wayland
New image is not generated in Klipper’s data folder over a certain size, but shortly, in 0-2 seconds the system realizes it cannot create it and usable record is generated.

BUT those images shown in imageviewers like Gwenview and Qimgv are existing images, with which Gwenview and Qimgv works directly, without embedding them in other formats. They are just viewers. Even if, for example, when cropping an image in Gwenview: after choosing the cropped area and applying it, Gwenview attentions me that changes where made and what I want to do – save it as a new file or replace the original, or save all changes (for all files). BUT if in this estate, before saving, but already after applied cropping, I choose to copy the image, it wont copy the cropped one, but the original one.

I concluded that Gwenview itself do not creates a new temporary file on which it works, so it is completely unnecessary that Klipper to create a completely new file when copying, instead of just pointing to the source file.

The hangup is one problem.

The creation of new images in Klipper’s data folder in vain when copying from Gwenview or Qimgv (while the text records belonging to the clipboard entry in Klipper’s data folder pointing to the original source file) is a second one.

And this second one is what bothers me most at this moment. If it would work correctly, without generating that inutile image, I could manage to use Klipper in Never save in history mode, so that images from other apps not being saved, only those coming from sort of built-in, tightly related apps to plasma like dolphin or Gwenview.

I should let this bug report as a duplicate of the Nimbus problem and the second discovery, which directly affects me to be a new one?

I attach Klipper data tested on tumbleweed, to have the X11 and Wayland behavior on the latest plasma 6.5.2 tested?. Three times klipper on X11 acted differently with the upscaled image. https://mega.nz/file/ZAIxEbJL#Y4DbONY2_8b27RmWscQK0bz6q8H84OkV7J-w66fzlBg

The screenshot is from the first X11 test. There was a first copy from Dolphin, second one from Gwenview with test.jpg, repeating the same with the upscaled image.

On the wayThenX11 klipper data, I copied first in Wayland then recopied on X11. X11 recognized after hang the test.jpg clipboard record, but not the upscaled one. It created an errored one.

In the data folders the ones with an empty file or a small thumbnail image are from the upscaled image.