Hi, I’m running Plasma 6.2.5 Wayland session on Arch Linux, kernel 6.12.8-arch1-1.
Hardware: i7-11800H, RTX 3070 Mobile (driver v. 565.77), 32 GiB RAM.
When I open GIMP, select part of an image, copy it to clipboard, and paste it into Firefox with a website that supports pasting from clipboard (Zoho’s webmail in this case), KDE hangs - cursor disappears and the screen remains frozen.
Despite the display being frozen, the system seems to be running, because when I disconnect an USB accessory, the device disconnected sound plays through the speakers.
Switching to TTY doesn’t work.
Only way to recover is to hard reset the computer or reboot using SysRq.
This only happens when the image has higher resolution (16MP photo for example).
When I re-open GIMP after reboot, it shows a dialog saying that the program has previously crashed and whether I want to recover my data.
This seems to indicate that GIMP crashes when working with the clipboard and takes the KDE down with it.
I’m wondering whether this is a KDE bug or an nVidia bug, or something else even.
I guess it could also be something to do with Firefox or GIMP, but I don’t think the DE should allow user app to cause it to freeze/crash anyway.
Anyways. I have no idea where to even start investigating, where to find relevant logs to share, in order to write an useful bug report.
The catch there is that what applications are allowed to do to the overall system is, in large part, controlled by system components at a layer below the desktop environment - ex. things like the kernel and its OOM killer.
Heading to your Application Launcher and running the Crashed Processes Viewer might help give a lead on which application is crashing first, by checking the timestamps correlating to when it happened? If that shows you which application went down first, then following the “Retrieving a backtrace using coredumpctl” section here might help get the details needed for a solid bug report, whether it’s to the KDE Bugtracking System for KDE software, or to the appropriate project if it’s not.
@johnandmegh
Thanks for the explanation.
Bummer the Kernel doesn’t treat the DE in any special way, giving it some preference over other apps.
I think Windows has gotten this right, no misbehaving program ever prevented me from opening a task manager and killing it, though I do remember how slow that sometimes was during the XP era.
Loosing keyboard/mouse input and video output on Linux/Wayland/KDE because of a misbehaving program is a tad unfortunate behavior from user perspective, as it leaves no room to recover the system, resulting in data loss.
Crashed Processes Viewer sadly doesn’t contain anything of relevance, only old reports of Spotify and ADB crashing.
@krake
I’ll try to install X11 and try to reproduce it there during next weekend (can’t risk breaking the system during the week when I’m working).
I’m afraid there is no way to drag a selection of picture from GIMP, at least I was not able to find any.
Thinking about what I wrote, I search the web for more frozen system recovery options on Linux, and found a SysRq shortcut that invokes OOM killer for cases when the freeze is caused by low available memory.
Invoking OOM killer by SysRq+F kills Firefox and the DE immediately recovers.
It would be nice if KDE was able to this automatically when the DE is effectively frozen because of the low memory situation, since most users will have no idea what’s going on (+SysRq is usually disabled by default) and will have to hard-reset anyway.
I left the system on for couple of hours last time and it never self-recovered, just remained frozen.
The real question though is why this copy-and-past operation causes OOM event in the first place.
Pasting the selection into Dolphin creates ~10 MiB file, which is a lot less than 32 GiB of RAM + 32 GiB of SWAP.
I’m starting to think this is some sort of bug in Firefox.
Yeah, I do think there’s something there. For what it’s worth, I notice significantly more lag and CPU strain in Firefox than in Chromium-based browsers when dragging and dropping - even when just dragging a single ~4MB image file from Dolphin into the Proton Drive web app.
I wonder if we could find an additional “paste target” to test against.
Dolphin is great to check if it works in principle but since it only writes the pasted data into a file it is not quite the same as an application that actually consumes the data.
Firefoxm on the other hand, will likely try to interpret/decode the data to create a thumbnail.
Another thing to try would be
copy in GIMP
verify in KDE’s clipboard history that you have the content in there
close GIMP
verify the content is still in the history
Paste in Firefox
I.e. making the KDE clipboard the source instead of GIMP.
Absolutely!
I would even consider testing this with a different user account so your session never gets switched from Wayland to X11
Copying from KDE’s Clipboard History after the GIMP was closed and pasting into Firefox doesn’t result in a system freeze, the image appears in Firefox as expected.
We might be looking at a case in which a certain transfer format triggered the issue.
During clipboard or drag&drop operations the source will offer its content in any number of formats and the target picks one and then gets the data in that format.
So it could be that KDE’s clipboard manager picked something like “PNG” when it received the data from GIMP but Firefox would have picked some other choice when GIMP was still the “owner” of the clipboard.
Not sure if there are any tools or logs which would give us information on such details. Might need someone with a GIMP or Firefox built from source to look into.
I had a chance to test it on Xorg session, no problem there, pasting is immediate.
Testing the same system on a different hardware (Ultra 9 185H, 32GB memory, Intel iGPU), on Wayland session, results in a DE freeze for couple of seconds, but it recovers and the image gets pasted, unlike on the hardware from the first post, where the system never recovers.
I am wondering if we are seeing a sort of “compatibility bug”.
What if both GIMP and Firefox are running as X11 applications in your Wayland session and the communication is something like GIMP → XWayland → KWin_wayland → XWayland → Firefox?
Unfortunately I don’t really know how we could check for that.
I guess at this point it could be worthwhile to file a bug report with either of the two applications.
