GNOME Bugzilla – Bug 172881
Reproducible Crash with large files and Debian SID (2.2.4)
Last modified: 2008-01-15 12:51:39 UTC
Easily reproducible. I'm assembling a front, back, and spine JPG covers of a book into a single file to export to PDF for a publisher. I create a new 300dpi XCF that is 4800x2900 bits (8MB xcf) and then open the three files. Selecting and copying (control A, control C) the front cover (a 260k JPG file) causes immediate crash. This happens every time unless I chant "don't crash don't crash don't crash" while I'm doing the copying, and even then sometimes Gimp doesn't hear me, even when I lean closer to the computer. (I have noticed a slight glow in my eyes now though.) I have 1GB of RAM and plenty of swap, and I increased tile caches from the default 64MB to 512 MB to see if it would help. I do have SMP (2x2Ghz athlon) if that might be the cause. I launched it from the command line to get the crash details: $ gimp --version GIMP version 2.2.4 $ gimp sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/jpeg' (jpeg) sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/png' (png) sending pixbuf data as 'image/jpeg' (jpeg) 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 896500 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:9385): LibGimpBase-WARNING **: script-fu: wire_read(): error Happy to provide files (in a tarball via email or an http download link) if they would help. I'm using 2.2.4 on Sid, and no related crash reports seem to have been filed. $gimp --sync 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 177527 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:9538): LibGimpBase-WARNING **: script-fu: wire_read(): error
You get this when doing copy and paste in the same application? It seems that you are running one of these broken-by-design clipboard managers then. There is no reason why the contents of the clipboard should be transferred to the X server. I suggest you stop using this clipboard manager daemon. There seems to be a bug somewhere as well since this should of course not crash the application but this seems to be a bug in GTK+/GDK or your X server rather than a GIMP problem.
Brilliant! I killed klipper (I guess it's KDE's version of the Macintosh scrapbook, which really was an ingenious invention, but, hey, if it doesn't work..) and that fixed it. Thanks Sven!!! And thanks for the rapid response! Should we leave this open and/or do you need additional details to figure out where the corresponding bug in Gimp is?
The corresponding bug is most likely a problem with large X selections. Thus the problem is either in klipper, GDK or your X server. We would need a test case that allows to reproduce the problem. I have tried to reproduce it here using a sane clipboard manager (one that only stores the data on request) and GIMP HEAD, and I had no problems with large clipboard data. If you are interested in getting this fixed, please make a simple test case and file a bug report for the relevant product.
*** Bug 314083 has been marked as a duplicate of this bug. ***
We now have a test application in the GIMP source tree that allows us to try all kinds of clipboard operations. This small test app is located in the tools directory in the GIMP source tree. You could try to reproduce your problem using this test program.
*** Bug 327910 has been marked as a duplicate of this bug. ***
I suspect this needs to be set NEEDINFO, since we need info on this and the issue is still there for people using Klipper. Anyone with KDE willing to give the test application a try?
If you point me in the right direction. I have some time on my hands so I may be able to do some tests. I am only a user but my offer help is there. Point me in the direction (name) of the test app and I will see what I can find. I have a feeling I first had this problem with kde 3.5 (before i down graded to stable) but I cant remember now. Does this happen in kde 3.5?
Resolving as OBSOLETE because it has been NEEDINFO since January and there have been many relevant changes, both the GIMP and KDE. Please reopen if the bug can still be observed and you can help figure it out.
*** Bug 370423 has been marked as a duplicate of this bug. ***
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411285 finally sheds some light on this issue and it has a stack trace that clearly shows that the bug is GdkPixbuf in the Windows ICO save module.
Applied a workaround for the crash to trunk. 2007-02-18 Sven Neumann <sven@gimp.org> * app/widgets/gimppixbuf.c (gimp_pixbuf_targets_add): skip Windows ICO as writable format. It's not well suited as a general image exchange format and the GdkPixbuf save routine seems to be buggy. Use of Klipper and similar clipboard managers is still very much discouraged as it will still cause GIMP to block for a while whenever anything is copied, even if that content is only meant to be pasted in GIMP again. Please use http://people.imendio.com/andersca/archives/clipboard-manager-0.3.tar.gz instead.