GNOME Bugzilla – Bug 314083
crash on copy of rectangular region of JPEG
Last modified: 2008-01-15 12:58:59 UTC
Distribution/Version: Suse 9.3 - Start GIMP on Suse 9.3 (KDE) - Open JPEG (sample available on request) - Use "select rectangular regions" to select most of the JPEG (i.e. cropping a picture) - Copy On some pictures, copy goes away for a relatively long time (20-30 seconds?) & then crashes. It happens on perhaps 1 in 20 pictures that I take - in any one set of pictures, there will normally be at least one which crashes gimp. The crash is not 100% reproducible, if I select a different region, I can normally find one which will copy without a crash & then continue processing. Below is the output generated in the terminal. The first picture did not cause a crash, the second one did. The pictures are straight out of a Canon S2IS in highest quality mode. ------------------------------------------------------------------ photos2/20_08_05_wsr> gimp opened thumbnail at 160 x 120 opened thumbnail at 160 x 120 sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/jpeg' (jpeg) offered type: text/plain;charset=UTF-8 offered type: text/plain;charset=ISO-10646-UCS-2 offered type: text/plain offered type: text/plain;charset=utf-8 offered type: UTF8_STRING offered type: TEXT offered type: COMPOUND_TEXT offered type: STRING offered type: TARGETS offered type: MULTIPLE offered type: TIMESTAMP checking pixbuf format 'png' - checking mime type 'image/png' checking pixbuf format 'wbmp' - checking mime type 'image/vnd.wap.wbmp' checking pixbuf format 'wmf' - checking mime type 'image/x-wmf' checking pixbuf format 'ani' - checking mime type 'application/x-navi-animation' checking pixbuf format 'bmp' - checking mime type 'image/bmp' - checking mime type 'image/x-bmp' - checking mime type 'image/x-MS-bmp' checking pixbuf format 'ico' - checking mime type 'image/x-icon' checking pixbuf format 'pcx' - checking mime type 'image/x-pcx' checking pixbuf format 'pnm' - checking mime type 'image/x-portable-anymap' - checking mime type 'image/x-portable-bitmap' - checking mime type 'image/x-portable-graymap' - checking mime type 'image/x-portable-pixmap' checking pixbuf format 'ras' - checking mime type 'image/x-cmu-raster' - checking mime type 'image/x-sun-raster' checking pixbuf format 'tga' - checking mime type 'image/x-tga' checking pixbuf format 'xbm' - checking mime type 'image/x-xbitmap' checking pixbuf format 'tiff' - checking mime type 'image/tiff' checking pixbuf format 'xpm' - checking mime type 'image/x-xpixmap' checking pixbuf format 'svg' - checking mime type 'image/svg+xml' - checking mime type 'image/svg' - checking mime type 'image/svg-xml' - checking mime type 'image/vnd.adobe.svg+xml' - checking mime type 'text/xml-svg' checking pixbuf format 'gif' - checking mime type 'image/gif' checking pixbuf format 'jpeg' - checking mime type 'image/jpeg' opened thumbnail at 160 x 120 sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/jpeg' (jpeg) (gimp:30879): Gdk-WARNING **: gdkproperty-x11.c:309 invalid X atom: 400 sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/jpeg' (jpeg) 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 1191119 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:30882): LibGimpBase-WARNING **: script-fu: wire_read(): error
Two additional pieces of information: a) I have found an image where select-all, copy crashes GIMP 2.2.4 100% of the time. I can supply this by email on request. b) I have tested that image on gimp 2.0.4 (Suse 9.2) and there are no problems at all. In fact, the copy operation completes almost immediately (<1 second) as opposed to 20-30 seconds.
You probably have a clipboard manager like klipper running, that unnecessarily requests every clipboard content when its changed. This makes GIMP encode the image for klipper, which unfortunately takes quite some time. while the GIMP should not crash, it is hard to debug, as there is quite some interaction between Gimp, GTK+, X-Server and klipper, we'd need a simple program to reproduce that problem. Can you check if you have clipper running and if stopping it works around the problem? If this is the case then this is a duplicate of bug #172881.
Stopping klipper makes everything work the way it should. Thanks a lot! You may want to find a way to make problem 172881 more visible since what I'm running is a new & relatively vanilla Suse 9.3 and I suspect other people will trip across this.
Please file a bug report against SUSE and ask them to disable Klipper by default. It is broken by design (see http://svenfoo.geekheim.de/index.php/2005-06-18/why-klipper-is-bad/) and the Klipper developers don't seem willing to fix this problem. But then, even with a broken clipboard manager, GIMP shouldn't crash here. The error message seems to indicate that there's also a problem with the X server.
*** This bug has been marked as a duplicate of 172881 ***