After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573860 - Cropping Related Hang
Cropping Related Hang
Status: RESOLVED DUPLICATE of bug 559716
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal critical
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-03 04:31 UTC by murvk
Modified: 2011-03-21 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace from hung gimp (17.97 KB, text/plain)
2010-08-26 15:57 UTC, Phil Harper
Details

Description murvk 2009-03-03 04:31:23 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.
Comment 1 Michael Schumacher 2009-03-03 11:59:10 UTC
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).
Comment 2 Sven Neumann 2009-03-03 14:39:08 UTC
Probably related to, if not a duplicate of, bug #567393.
Comment 3 Massimo 2009-07-07 11:56:30 UTC
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.                                                   
Comment 4 Martin Nordholts 2009-07-07 18:11:07 UTC
I'm pretty sure I had <= at first, or during some experimentation, that that this causes other problems.
Comment 5 Michael Schumacher 2009-07-08 15:36:31 UTC
Can this still be reproduced with a recent build of git master?
Comment 6 Pedro Gimeno 2010-01-29 22:11:58 UTC
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:

  • #0 gimp_image_get_width
    at .../gimp-2.6.8/./app/core/gimpimage.c line 1575
  • #1 gimp_rectangle_tool_get_constraints
    at .../gimp-2.6.8/./app/tools/gimprectangletool.c line 4028
  • #2 gimp_rectangle_tool_clamp
    at .../gimp-2.6.8/./app/tools/gimprectangletool.c line 3195
  • #3 gimp_rectangle_tool_update_with_coord
    at .../gimp-2.6.8/./app/tools/gimprectangletool.c line 4079
  • #4 gimp_rectangle_tool_synthesize_motion
    at .../gimp-2.6.8/./app/tools/gimprectangletool.c line 2215
  • #5 gimp_rectangle_tool_options_notify
    at .../gimp-2.6.8/./app/tools/gimprectangletool.c line 2314
  • #6 g_cclosure_marshal_VOID__PARAM
    from /usr/lib/libgobject-2.0.so.0
  • #7 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #8 ??
    from /usr/lib/libgobject-2.0.so.0
  • #9 ??
  • #10 ??

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.
Comment 7 Tor Lillqvist 2010-08-25 11:25:19 UTC
What does "using the UI button by holding it down a second or two" mean? What is "the UI button"?
Comment 8 Tor Lillqvist 2010-08-26 14:16:23 UTC
murvk, Massimo or Pedro, can you reproduce the problem with 2.6.10?
Comment 9 Pedro Gimeno 2010-08-26 14:53:33 UTC
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.
Comment 10 Phil Harper 2010-08-26 15:57:55 UTC
Created attachment 168816 [details]
backtrace from hung gimp

backtrace from a hung gimp reproduced with gimp 2.6.6 on ubuntu 9.04
Comment 11 Jernej Simončič 2010-08-26 16:04:03 UTC
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.
Comment 12 Tor Lillqvist 2010-08-26 16:10:15 UTC
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.
Comment 13 Martin Nordholts 2011-03-14 07:47:31 UTC
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
Comment 14 Michael Natterer 2011-03-21 13:35:00 UTC
It's all incarnations of the same problem.

*** This bug has been marked as a duplicate of bug 559716 ***