GNOME Bugzilla – Bug 573860
Cropping Related Hang
Last modified: 2011-03-21 13:35:00 UTC
Steps to reproduce: 1. Shift + c to crop an image 2. Crop to the rightmost side of the image 3. Try to increase the x-position of the crop using the UI button by holding it down a second or two 4. It should lock up Stack trace: Other information: Whatever the actual cause of the hangup/crash the solution should be simple to code. The correct behavior for this situation should be: when you ask for the x-position of your crop to be increased when the x-size already puts the crop's rightmost vertical line at, or past, the x-limit of your image/canvas the cropping rectangle's size should shrink to accommodate the increase in x-position.
I can't reproduce this on Microsoft Windows. The seem to be some redraw events, maybe this causes problems on X11... maybe the code used here could return earlier if no change will be made by the action, but that's just a guess (without even having looked at the code at all).
Probably related to, if not a duplicate of, bug #567393.
To replicate this bug with the release 2.6.6: 1 - Ctrl+N Enter (New document) 2 - Zoom at 200% 3 - Scroll to the right until the right border is visible 4 - Shift+C (Crop tool) 5 - And now repeat steps 2 and 3 of the original bug report: Crop to the rightmost side of the image Try to increase the x-position of the crop using the UI button In one out of four trials (with different cropping rectangles) you should see the lock up. It happens when the left x coordinate of the rectangle is an odd integer and a half (for example 475.5), though the gui doesn't show the tenths. A quick and dirty hack to fix this is to change the macro #define PIXEL_FEQUAL(a,b) (fabs ((a) - (b)) < 0.5) in file app/tools/gimprectangletool.c #define PIXEL_FEQUAL(a,b) (fabs ((a) - (b)) <= 0.5) but I can't say this won't break something else.
I'm pretty sure I had <= at first, or during some experimentation, that that this causes other problems.
Can this still be reproduced with a recent build of git master?
I ran into this on 2.6.8 by accident, at 200% zoom too. The zoom ratio seems important. I attached gdb to the running locked instance and came to the same conclusion as Massimo about the cause of problems (not so sure about the solution though): I cont'd and ^C'd and bt'd a few times. Most backtraces were uninteresting, as they showed mostly unrelated or unknown libraries (glib, libc6, ??, etc. -- I don't have debug info for all the libraries.) I got an interesting one though:
+ Trace 220312
It seemed that gimp_rectangle_tool_synthesize_motion was being called repeatedly. Here's the part that seemed to cause trouble in my case (line 2314 is the gimp_rectangle_tool_synthesize_motion call below): else if (strcmp (pspec->name, "height") == 0 && !PIXEL_FEQUAL (private->y2 - private->y1, options_private->height)) { /* Calculate x2, y2 that will create a rectangle of given height, for the * current options. */ gdouble y2; if (options_private->fixed_center) { y2 = private->center_y_on_fixed_center + options_private->height / 2; } else { y2 = private->y1 + options_private->height; } gimp_rectangle_tool_synthesize_motion (rect_tool, GIMP_RECTANGLE_TOOL_RESIZING_BOTTOM, private->x2, y2); } I put a breakpoint in the second 'if' and did: (gdb) print private->y2-private->y1 $42 = 66.5 (gdb) print options_private->height $43 = 67 (gdb) print private->y1 $45 = 8.5 (gdb) set private->y1 = 8 (gdb) cont That did it. A few cont's more and Gimp was responsive again.
What does "using the UI button by holding it down a second or two" mean? What is "the UI button"?
murvk, Massimo or Pedro, can you reproduce the problem with 2.6.10?
I can't try it on 2.6.10 at this moment. I believe the OP means the spinner button in the tool options window. Here's a full repro that works in my old 2.6.8-1 from Debian Testing, I believe it will be the same in more recent versions: - Create a default image, 420x300. - Zoom to 200% (important). Press Ctrl-E if desired (doesn't affect, but it's preferable to have the right or bottom margin visible). - Select the crop tool. - Create a crop rectangle, close to the right border but not too much, e.g. about 20 to 100 pixels from the right border. - Go to the Tool Options window or tab, and use the spinner button on X or Y size or position (all four cause this) to raise it, and keep it pressed until the rectangle reaches the right or bottom margin. - If it doesn't hang right when reaching the margin, create another crop rectangle (don't modify the existing one) and increase the size again using the tool options. It hangs 1 out of 4 times on average, as reported by Massimo. The hang is evident by the flickering lines and the irresponsivity of the GUI.
Created attachment 168816 [details] backtrace from hung gimp backtrace from a hung gimp reproduced with gimp 2.6.6 on ubuntu 9.04
I can reproduce this both on 32 and 64-bit GIMP for Windows 2.6.10 (where 64bit version uses GTK+ 2.20.1). I'll try to get a backtrace. Note that I can reproduce this by typing a large number in the crop width/height setting - I usually just type 5555 and press tab, and in about one in 10 cases, the crop rectangle will start flashing, and GIMP hangs.
Thanks for the clearer instructions, now it's indeed much easier to reproduce. It seems that comments 3 and 6 are quite on the right track.
This exists in 2.6 and duplicates are not super common, but it still is a serious bug. But let's first release 2.8
It's all incarnations of the same problem. *** This bug has been marked as a duplicate of bug 559716 ***