GNOME Bugzilla – Bug 743717
Crashes on clipboard operation, influence by clipboard helper applications is suspected
Last modified: 2018-05-02 16:24:10 UTC
Created attachment 295782 [details] Mac OS Problem Reporter result I have a selected area and i press "Command + X", then gimp crashes!
It looks like a retain operation is done on an invalid object. We need to try to reproduce this to be able to get to the bottom of this.
*** Bug 750476 has been marked as a duplicate of this bug. ***
*** Bug 747687 has been marked as a duplicate of this bug. ***
*** Bug 751110 has been marked as a duplicate of this bug. ***
*** Bug 747872 has been marked as a duplicate of this bug. ***
Created attachment 307616 [details] clipboard issues its an clipboard related issue, causing instability and finally, a crash. This includes copy, paste, paste visible, cut, ect. -ive seen that behavior more than one time. Unfortunately i wasnt able to simulate that bug, i had to get the bug report during work.
I confirm the same on osx mavericks. exact reproduction: in a single layer imported png, select all; copy to clipboard ; crash does not seem to occur if I simply copy to clipboard (copy pixels), but I note that the image does not have a selection outline.
I modify my comment after experimenting with different sequences. Basically, it just crashes after 2 copy to clipboard operations, no matter what.
Haven't been able to reproduce on 10.9 and 10.10 with the GIMP 2.8.14 DMG from gimp.org and git master. Also tried with NSZombie debugging turned on and nothing out of the ordinary appears on the terminal. Is there a correlation with image size? I.e., does this only happen with large images, or also on small images? If it only happens on large images, what is the approximate image size?
Quit clipboard helper (copy'm paste or other apps) before using Gimp and the problem is over.
Do you guys use any of these cliphoard helper apps? If yes, does disabling fix the problem? If it does, what apps were it exactly? GIMP still should not crash in the presence of such tools.
(In reply to jjb from comment #10) > Quit clipboard helper (copy'm paste or other apps) before using Gimp and the > problem is over. Thanks that's good to know. (In reply to Michael Natterer from comment #11) > Do you guys use any of these cliphoard helper apps? If yes, does disabling > fix the problem? If it does, what apps were it exactly? GIMP still should > not crash in the presence of such tools. I was already thinking of trying a clipboard helper yesterday, but didn't have one installed. I vaguely remember some GTK+ clipboard bug that was only triggered with a clipboard helper active. IIRC clipboard transfers are done on demand. So, with a clipboard helper active, this demand is "there" immediately. Otherwise, nothing happens until an actual paste information. Also, clipboard helpers probably transfer all possible formats, not just one. I will try again soon with a clipboard helper active, that might possibly reproduce it. The question now becomes if the crashes also occur *without* a clipboard helper active :)
There is a clipboard-related memory leak when other application grab the clipboard, see bug 699625.
*** Bug 732579 has been marked as a duplicate of this bug. ***
*** Bug 763061 has been marked as a duplicate of this bug. ***
*** Bug 762532 has been marked as a duplicate of this bug. ***
Up till now I have not been able to reproduce any clipboard issues. We need additional information: in particular on any (clipboard-related) activity before the crash in GIMP is triggered. It would be interesting to know, for example, whether any large data was present on the clipboard.
The GIMP does not collapse when I before copy and paste in GIMP i do disable the Copy'emPaste, a clipboard extender. So my thoughts are the clipboard helper and Gimp is not a good combination.
*** Bug 743712 has been marked as a duplicate of this bug. ***
the copy paste feature is important in most applications, and gimp makes no exception. A workaround to prevent crashes (works always) is to save our file first, before doing any copy or paste or cut.
*** Bug 771958 has been marked as a duplicate of this bug. ***
I don't know if it's appropriate to ask, but is there any chance this is going to get fixed in the near future? You can't image how obnoxious it is. Since it's not caused by "just a clipboard manager" but instead by Keyboard Maestro, which has become indispensable to me, just turning it off is hardly a good option. Especially since I have macros for working in GIMP.
Dan, maybe you could ask the developers of Keyboard Maestro if they have any hints of what is happening there? The source of GTK+ is available to them, but their application is closed source, so we can't check what they do.
I'll ask. I'll report back when I get an answer.
This chrome extension will get your machine into the state to tickle this bug https://github.com/arkarkark/chrome-copy-bug
Here's the answers I received: I will have a look. I think the pertinent thing to tell them is that after they put something on the clipboard, Keyboard Maestro will read every flavor that is not marked private. There are two possible issues: 1) They may expect some "private" flavors to never be read, and when another application reads them bad things happen. 2) Or, less likely, they may be putting the flavors on slowly, and flavors are since there is no "start/finished" for putting clipboard flavors on, they may be getting flavors read while they are still creating other flavors and that may cause bad things to happen. ------------------------------------- I had a look at the source for GTK, but I could not even find the routine that crashed (gtk_clipboard_set_contents). -------------------------------------
@Dan Thomas: I have a trial of Keyboard Maestro installed and I cannot immediately reproduce any crash with GIMP. I have been putting very large images on the clipboard for a while. GIMP sometimes blocks, but it does not crash for me. Could you tell us more about your environment? We would be interested in: - OS X version. - Version of Keyboard Maestro you are using. - Hardware: in particular CPU & amount of RAM. - Size (dimensions) of the images you are editing - The number of images that need to be open in order to reproduce the issue. Can you always reproduce a GIMP crash "at once", or does it take a while before it appears?
Well now, that's odd. It doesn't crash now for me either. I haven't tried it recently, because there was no point, since it always crashed. Until now. Typical, right? ;) I have the latest version of KM, 7.3.1. I wonder if Peter changed something. I'll ask him. and report back. Thanks for looking into this!
Did you try the chrome extension listed in comment 25 https://bugzilla.gnome.org/show_bug.cgi?id=743717#c25 that reliably gets gimp into the state where it crashes when I double click or copy something (usually in a file dialog).
(In reply to Dan Thomas from comment #28) > Well now, that's odd. It doesn't crash now for me either. I haven't tried it > recently, because there was no point, since it always crashed. Until now. > > Typical, right? ;) Hah! I think it's a timing-related issue. In August I wrote my own "clipboard torture" utility, but I only managed to reproduce the issue twice with that by having a lot of luck. Last week I didn't manage to reproduce it. Peter's comment in comment 26 (point 2) also suggests a timing issue. So I think as a next step, I am going to try this on a less powerful machine. If that doesn't work immediately, I have to go back to the drawing board and figure another test application based on the crash dump I managed to extract in August. (In reply to ark from comment #29) > Did you try the chrome extension listed in comment 25 > https://bugzilla.gnome.org/show_bug.cgi?id=743717#c25 that reliably gets > gimp into the state where it crashes when I double click or copy something > (usually in a file dialog). I just tried it (I didn't have Chrome installed before) with the latest Chrome. I didn't manage to get GIMP to crash with both your Chrome extension and Keyboard Maestro running. The warnings "could not allocate block for pasteboard" did appear in Console.app, so your extension must have been active.
When I reported the bug, it had nothing to do with timing. I could reproduce it every single time. In a variety of ways. That's why I felt confident enough to post the bug, since I felt certain anyone could reproduce it. Silly me. I've been a developer long enough to know that the Heisenberg Principle applies to bug testing, as much as anything else! :) I've undoubtedly applied some OS patches since the last time, although I'm still on the same major version. I wonder if that could have changed anything related to this? Perhaps some security patch that relates to clipboards?
*** Bug 774294 has been marked as a duplicate of this bug. ***
*** Bug 774606 has been marked as a duplicate of this bug. ***
I finally found the way to reliably reproduce this bug: 1. Ensure some kind of clipboard manager is running (e.g. keyboard maestro). 2. Start GIMP 3. Open some image 4. Make a *small* selection, the selection must be smaller than e.g. 32x32 pixels. 5. Copy 6. Copy again 7. GIMP should crash Due to the lack of progress I resorted again to carefully analyzing the one crash I managed to trigger in the last year. I found a new lead in the GTK+ commit history, which I used to figure out this reproduction instruction. So it turns out the bug is not timing related, rather the selection that is copied must be small enough. This seems to be because for larger selections some of the promised data types are not filled and get a size of 0. Clipboard managers seem to not retrieve data items with a zero size (makes sense). Now on to the bug. The problem is in the Quartz clipboard implementation in GTK+. Commit 4a8df7a33c298d22bf78b947d0e861fc03ec70e1 wrongly assumes there is no need to keep a reference to the clipboard owner ourselves. The problem is that NSPasteboard will release the owner as soon as all data items have been transferred. When on the next copy action GTK+ tries to re-use this clipboard owner, it will already have been released. When you run GIMP with NSZombieEnabled=YES, the following log entry appears which confirms this: 2017-01-01 12:54:18.608 gimp-2.8[913:34563] *** -[GtkClipboardOwner retain]: message sent to deallocated instance 0x7fb04ef73030
Reassigning to GTK+. A patch is forthcoming.
Awesome! Thanks for the hard work!
Created attachment 342699 [details] [review] Patch: this seems to fix it
(In reply to Kristian Rietveld from comment #37) > Created attachment 342699 [details] [review] [review] > Patch: this seems to fix it On a second thought, we probably want to release the previous owner after declareTypes. Need to test this.
Created attachment 344992 [details] [review] Updated patch that checks whether the old owner needs releasing after declaring types using the new owner
(GIMP related comment: the above patch ships in the GIMP 2.8.20 DMG).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/529.