Bug 118792

Summary:	'gimp received an X Window System error' while copying from large pictures
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Florian Beißner <florian.beissner>
Component:	Other	Assignee:	E-mail List <gnome-bugs>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P3 - Medium
Version:	RC 1
Target Milestone:	---
Hardware:	i586
OS:	All
Whiteboard:
Found By:	Beta-Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Florian Beißner 2005-09-26 13:31:47 UTC

When I try to copy or cut a piece from a large picture (1MB jpeg) the gimp
window does not refresh at first and in some cases gimp crashes entirely leaving
the following message in a console:

sending pixbuf data as 'image/png' (png)
sending pixbuf data as 'image/bmp' (bmp)
sending pixbuf data as 'image/jpeg' (jpeg)
sending pixbuf data as 'image/png' (png)
sending pixbuf data as 'image/bmp' (bmp)
The program 'gimp' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 196808 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

(script-fu:11752): LibGimpBase-WARNING **: script-fu: wire_read(): error

Comment 1 JP Rosevear 2005-09-26 14:28:40 UTC

Federico, please talk to the gimp guys about this bug.

Comment 2 Federico Mena Quintero 2005-09-26 16:16:16 UTC

Are you running some sort of clipboard manager?  If so, do you know if it
crashed while doing the copy operation?

Comment 3 Florian Beißner 2005-09-26 19:48:09 UTC

Klipper was running. Unfortunately I was unable to reproduce the behavior of
gimp. I have no idea, what was different last time. When I switch off Klipper I
get no refreshing problems and everything runs smooth.

Comment 4 Federico Mena Quintero 2005-09-27 00:15:19 UTC

I'm pretty sure that Klipper is the problem.  That little log you posted
indicates that the GIMP is being requested to send the data in as many formats
as it supports.  Near the end, Klipper dies and leaves the GIMP hanging with a
BadWindow.

Now, the GIMP or GTK+ could be made more resilient when the requesting program
going away in the middle of a selection transfer.  But "old-style" clipboard
managers like Klipper can cause many problems with data-intensive apps like the
GIMP and Gnumeric - their use is not recommended.

Comment 5 JP Rosevear 2005-10-14 13:01:12 UTC

Moving to the KDE guys on the klipper issue

Comment 6 Dirk Mueller 2006-02-06 10:40:11 UTC

its a gimp bug not supporting TARGET_SIZES btw.

Comment 7 Lubos Lunak 2006-02-06 14:10:56 UTC

Sorry, but comment #4 is wrong, in several places.
- There's no indication of Klipper crashing in this bugreport, besides the BadWindow, which could be anything including a bug in Gtk clipboard implementation.
- I'm reasonably sure both Klipper and QClipboard are technically correct implementations of clipboard handling, so if Gimp crashes, it's Gimp's fault.
- If the problem was really caused by Klipper going away, then the problem can happen also with any other program that just happens to request clipboard contents and go away.
- There's nothing wrong (or unfixable at least) with running Klipper. If somebody feels like reading a bit, http://www.kdedevelopers.org/node/1787 sums up all Klipper problems and "problems" quite well.
- To mitigate problems of applications like this, Klipper in 10.1 will default to ignoring images, which should avoid this Gimp problem. That will very likely change again when there's a decent support for TARGET_SIZES.

Reassigning back to gimp maintainers to fix the crash or just shrug it off.

Comment 8 Federico Mena Quintero 2006-04-11 19:01:31 UTC

Is this reproducible when klipper is running?

Is this *not* reproducible when klipper is *not* running?

Lubos, I had not heard of the TARGET_SIZES bug - could you please elaborate? :)

Comment 9 Lubos Lunak 2006-04-12 08:45:47 UTC

I'd expect the problem should be reproducible even without Klipper. My theory about what happens is:

Klipper (Qt's QClipboard class actually, so it could happen when copy&pasting to any Qt/KDE app) requests clipboard contents. It gets a list of all data formats GIMP supports and starts fetching image/png, which is done as INCR transfer due to large size of the png. But conversion from GIMP's internal representation to png takes too much time and since QClipboard::image() is synchronous API, it has a timeout. So the image/png transfer times out and QClipboard tries again with next data format (which is kind of stupid indeed). INCR transfers have no support for aborting or anything like that, so problems can be detected only using a timeout. My guess is that Gtk's clipboard implementation doesn't cope well with several pending INCR transfers at the same time triggered by this.

As for fixing this: As already said in comment #7, Klipper has now keeping of images in history disabled by default, so the chances of triggering this problem should be low, but I'd expect it can still happen in some relatively rare cases (e.g. if somebody tries to copy&paste from GIMP to a KDE app repeatedly with an image that's large enough on a machine that's slow enough).

WRT TARGET_SIZES, comment #6 is not correct. TARGET_SIZES comes from http://www.freedesktop.org/wiki/ClipboardManager and should be a way for Klipper to limit its impact on other apps (prevent it from fetching too large amounts of data). A simple opt-out would be insufficient because Klipper is not like GNOME's keep-data-after-app-exits daemon but it's clipboard history (see the already mentioned http://www.kdedevelopers.org/node/1787 if you have nothing to read while sipping your coffee :) ) and there are people who like Klipper keeping even other things than text in its history.

Comment 10 JP Rosevear 2006-10-31 16:10:42 UTC

Florian, are you still able to reproduce on 10.2?

Comment 11 JP Rosevear 2007-02-09 21:08:15 UTC

No response in several months and neither the gnome or kde teams have and real clue here, so I'm going to close this one.