GNOME Bugzilla – Bug 349483
Using transformation tools crashes GIMP
Last modified: 2008-01-15 13:10:25 UTC
Steps to reproduce: 0. Launch Gimp.app 1. Create a new file 2. Draw something, a squiggle, make a square, etc. 3. rotate the layer 4. repeat step three two or three times, you should get the app to crash. Stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c 0x00628adf in gdk_x11_draw_pixbuf () (gdb) thread apply all bt
+ Trace 69844
Thread 1 (process 20979 local thread 0x1307)
Other information: I'm running Gimp.app on OS X. I tried this same thing on version 2.2.8 on Linux and did not have this problem. Thanks!
Not that it's any of my business, but I did a little investigating of this. app/core/gimpdrawable-transform.c:gimp_drawable_transform_tiles_affine() contains a nested loop: for (y = y1; y < y2; y++) { /* stuff */ for (x = x1; x < x2; x++) { /* more stuff */ } } I wired it up a bit: count = 0; for (y = y1; y < y2; y++) { /* stuff */ for (x = x1; x < x2; x++) { count++; /* more stuff */ } } fprintf (stderr, "iterations = %d p1 = [%d %d] p2 = [%d %d] span = [%d %d]\n", count, x1, y1, x2, y2, x2-x1, y2-y1); Here are the results of doing a few rotates: iterations = 177555 p1 = [-34 -83] p2 = [411 316] span = [445 399] iterations = 275369 p1 = [-82 -138] p2 = [459 371] span = [541 509] iterations = 521259 p1 = [-175 -242] p2 = [552 475] span = [727 717] iterations = 1028195 p1 = [-319 -390] p2 = [696 623] span = [1015 1013] iterations = 1763583 p1 = [-475 -548] p2 = [852 781] span = [1327 1329] What appears to be happening is that at every rotation the resultant image size grows enough to encompass the rotated image-- After 20+ rotates, it gets to: iterations = 114041041 p1 = [-5151 -5223] p2 = [5528 5456] span = [10679 10679] That 114 /million/ iterations. I think maybe the original OSX problem may be that the size of the image blows memory. I did all this stuff under RHEL4 Linux--it doesn't blow up, but it does get /real/ slow. Another symptom, BTW, if you keep the number of grid lines constant, the grid spacing grows with every rotation--as the image size grows, dx/N and dy/N also grow. Using cvs HEAD as of 2006-08-05 13:25 EDT
BTW, forgot to mention, you can work around the problem by enabling "Clip result" on the Rotate menu.
None of this is really a bug, except of course the crash in gdk_x11_draw_pixbuf(). What version of GTK+ are you using?
Chris, could you tell us your Gtk+ version, please?
My rpm -q shows gtk2-2.4.13-19, but I don't guarantee that's what was in August--I've got the machine on Red Hat's RHN update service.
reopening as per last comment.
The code has changed drastic since the creation of the bug report. Is this still a problem?
The code in the 2.2 tree hasn't changed at all but it would indeed be interesting to know if this problem does occur with recent GIMP 2.3 releases. But then I doubt that a lot of people are using the development version on the Macintosh.
I can reproduce the bug on GIMP 2.3.16 @ OS X 10.4.9 @ Intel start the GIMP open an image, do a correction with the perspective tool do a correction with another transformation tool like scale or rotate get a GIMP crashing with: >jpeg-load: found EXIF block (7159 bytes) >loading menu '/opt/local/gimp-2.3/share/gimp/2.0/menus/image-menu.xml' for /image-menubar > >(gimp-2.3:8611): Gdk-CRITICAL **: gdk_pixmap_new: assertion `(width != 0) && (height != 0)' failed >/opt/local/gimp-2.3/bin/gimp-2.3: fatal error: Bus error >/opt/local/gimp-2.3/bin/gimp-2.3 (pid:8611): [E]xit, [H]alt, show [S]tack trace or [P]roceed: E > >(script-fu:8612): LibGimpBase-WARNING **: script-fu: wire_read(): error doing a gdb on gimp-2.3 showed: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c 0x0074d983 in draw_with_images () (gdb) bt
+ Trace 133141
Ok, there are actually two bugs here. For one, gdk_draw_pixbuf() accepts 0 width and 0 height. The X11 backend deals with that correctly and does nothing if compiled with USE_SHM. On Mac OS X however a different code path is taking and some code there doesn't like width or height to be zero. This needs to be reported against GDK. I will take care of that. We can easily fix this in GIMP by checking width before calling gdk_draw_pixbuf(). This fix should be done in both branches. I will also take care of that.
Fixed the crash in both branches: 2007-05-09 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-preview.c (gimp_display_shell_draw_tri_row) (gimp_display_shell_draw_tri_row_mask): don't call gdk_draw_pixbuf() with a zero width. Fixes bug #349483. I will do some more cleanups in trunk and report a bug against GTK+.
I've opened bug #437081 against GTK+.
*** Bug 440151 has been marked as a duplicate of this bug. ***
*** Bug 445133 has been marked as a duplicate of this bug. ***