GNOME Bugzilla – Bug 470282
gimp crashes soon after launch
Last modified: 2007-09-12 06:34:54 UTC
Steps to reproduce: 1. Start Gimp, load an image ; 2. Resize main window, zoom in, or edit a path 3. Stack trace: from gdb; my comments are prefixed with !! !! gimp launches Removing duplicate PDB procedure 'file-gif-save' registered by '/usr/local/lib/gimp/2.0/plug-ins/gif-save' !! image has been loaded !! resizing window Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47701539889392 (LWP 30200)] 0x0000000000478f15 in render_image_tile_fault_one_row (info=0x7fff4e79aea0) at gimpdisplayshell-render.c:935 935 DO_COMPONENT(ALPHA); (gdb) q The program is running. Exit anyway? (y or n) y jmt@gnopt:~$ (script-fu:30209): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error jmt@gnopt:~$ Other information: gimp on Debian GNU/Linux, amd-64, in a unstable chroot dedicated to gimp latest svn.
Please retest this against the updated current SVN, because I suspect this is a duplicate of bug #470302. If you are still albe to reproduce it, please provide a detailed step-by-step on how you did.
Gimp in amd64 chroot for debian unstable Using sources from svn, release 23397 : make distclean ./autogen.sh make && make install Then run gimp under gdb ; open a recent image ; resize image window ; zoom in using keypad + ; gimp crashes. Here is the backtrace : (gdb) bt full
+ Trace 158838
Are you sure that your source tree is clean and does not have any SVN conflicts when you update? This may look like a stupid question, but I cannot reproduce this problem so I would like to be sure that all recent changes are really included in your tree. It could also help to know the exact dimensions of the image that you are loading, as well as its zoom level just before you get this crash (which depends on the size of your screen).
jmt, we are waiting for feedback.
I just performed the following tests : - create a fresh amd64 unstable chroot ; build gimp from svn in this chroot. Result : gimp crashes like before on the test image. - install gimp-2.4~rc2 from Debian repository. Result : gimp crashes like before on the test image. I am finally inclined to think that the test image - which does not crash gimp-2.2 - has something wrong. Either from Ufraw (image is a NEF file from a Nikon D70), because any gimp-2.4 would also crash the ppm file issued from a standalone Ufraw, but the latest Ufraw has produced ppm files from the NEF image that did not crash gimp-2.4, or the xcf image has internal fields like paths which I remember have treated a bit quickly, mixing polygonal and non-polygonal in the same path for instance). I have been working these last days on a new version of the test image (NEF to ppm with standalone Ufraw, ppm to xcf with gimp-2.4 from Debian package) without troubles till now. But I am frustrated because I cannot understand what happends, and why an image giving no troubles to gimp-2.2 would create some on gimp-2.4.
Obviously a duplicate of bug #469567 *** This bug has been marked as a duplicate of 469567 ***