I can't reproduce this with GIMP 2.6.8 - GIMP does not freeze/crash.

Can you describe in more detail the exact steps to reproduce the bugs? How exactly did you preform the cropping?

If we don't enable the "Allow Growing" option, then after I type a larger value in the entry, when I click anywhere outside the tool-options tab, the entry updates itself to have a value which will not cause the image to grow. So, clicking on the handles on the canvas causes a regular crop (the value is updated so that the image will not be grown, and only then cropping is preformed with that value). Did you crop by clicking one of the on-canvas handles?

If we enable the "Allow Growing", then again I can't reproduce the crash/freeze - the image will be grown to the size you specified in the tool-options tab.

Screencast: http://www.youtube.com/watch?v=K2g_jOS4RGs

Could be the same problem as in bug #573860?

Could you experiment a bit and check if the hang (freeze) happens also if you have the image at 100% zoom, and/or slightly different image sizes?

It happens only if the crop selection is in rectangle form (300x93 for example), and is closer to the bottom, also seems to happen only to png images at 66.7% zoom.

I have encountered this bug twice as of Win32 GIMP v2.6.11 -- in both cases, I input a larger width on the Crop tool via keyboard and instead of trimming it to image size GIMP instead freezes up.  However, I haven't figured out a reliable way to produce the bug on demand.

I reproduced this just now as of last night's master.

GIMP is using 100% CPU and UI is blocked. I'll attach a couple of backtraces from two interrupts into the loop.

I don't have the _exact_ steps to reproduce as I was trying to debug another issues. But the rough steps are:

1. Create a A4 300 ppi image.
2. Select the crop tool
3. Set both the origin and size units to centimeters.
4. Use the crop tool to mark a region inside the image.
5. Now set the size of the crop region to something that maps outside the image, such as 300 x 300 (centimeters)

GIMP UI should freeze now.

Created attachment 183859 [details]
Backtrace from initial attach

Created attachment 183860 [details]
Let it run for a while, interrupted and backtrace

Created attachment 183861 [details]
Let it run for a while, interrupted and backtrace again

(In reply to comment #6)
> 1. Create a A4 300 ppi image.
> 2. Select the crop tool
> 3. Set both the origin and size units to centimeters.
> 4. Use the crop tool to mark a region inside the image.
> 5. Now set the size of the crop region to something that maps outside the
> image, such as 300 x 300 (centimeters)
> 
> GIMP UI should freeze now.

These steps are correct to reproduce the bug.

Setting status to NEW as this is a verified bug.

I think what's happening is that the freeze/thaw in gimp_rectangle_tool_update_options() doesn't have the intended effect.. "width" is updated, and that calls gimp_rectangle_tool_options_notify() again.

Also, this may be because some thing is not being initialized/created properly, because sometimes it works.

We were looking into this on the IRC channel, and it wasn't clear exactly what _block_by_func does.  So for the record, here is the implementation from the source (glib2.0-2.28.2):
/**
 * g_signal_handlers_block_by_func:
 * @instance: The instance to block handlers from.
 * @func: The C closure callback of the handlers (useless for non-C closures).
 * @data: The closure data of the handlers' closures.
 * 
 * Blocks all handlers on an instance that match @func and @data.
 * 
 * Returns: The number of handlers that matched.
 */
#define	g_signal_handlers_block_by_func(instance, func, data)		\
    g_signal_handlers_block_matched      ((instance),			\
	(GSignalMatchType) (G_SIGNAL_MATCH_FUNC | G_SIGNAL_MATCH_DATA),	\
	0, \
	0, \
	NULL, \
	(func), \
	(data))

The arguments of _matched are:
/**
 * g_signal_handlers_block_matched:
 * @instance: The instance to block handlers from.
 * @mask: Mask indicating which of @signal_id, @detail, @closure, @func
 *  and/or @data the handlers have to match.
 * @signal_id: Signal the handlers have to be connected to.
 * @detail: Signal detail the handlers have to be connected to.
 * @closure: The closure the handlers will invoke.
 * @func: The C closure callback of the handlers (useless for non-C closures).
 * @data: The closure data of the handlers' closures.
 *
 * Returns: The number of handlers that matched.
 */

Created attachment 183903 [details] [review]
A patch to add some debug messages

I was unable to repro this, so I couldn't do any real debugging.  My current (unfounded) hypothesis is that this is somehow related to floating point error.  The PIXEL_FEQUAL macro looks somewhat suspicious, especially considering that (from muks' first stack trace) synthesize_motion is somehow getting called with new_x and new_y = NNNN.5:

+ Trace 226399

The macro is defined as:
#define PIXEL_FEQUAL(a,b) (fabs ((a) - (b)) < 0.5)

By comparison, from my debugging (which did not result in unresponsiveness), I get the following:
synthesize_motion f(9) of(1) nx(35601.070866) ny(3284.000000) pcx(1324.000000) pcy(1744.000000) px1(168.000000) px2(2480.000000) py1(204.000000) py2(3284.000000)
update_options px1(168.000000) px2(2480.000000) py1(204.000000) py2(3284.000000) w(2312.000000) h(3080.000000)

When I set new_x to 300 (with units set to cm), I get a huge value that is nonetheless mostly integral.  Then by the time I get to update_options, the huge value's been filtered out. (Full debug log forthcoming)

Created attachment 183905 [details]
Debug log

Aforementioned full debug log, taken with the attached patch (#183903)

We have that vers same bug 4 times it seems.

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