GNOME Bugzilla – Bug 515415
Fatal Error Subsequent to GIMP Scale Tool
Last modified: 2008-10-30 20:09:26 UTC
Steps to reproduce: 1. Select Scale Tool 2. Use mode other than "pixel"--for example, "percent" or "inches"; lock X&Y together; enter new values (larger or smaller) for X or Y, or grab handle and move; "Scale"; scale appears to succeed. 3. Select a different Tool; Crash and Burn Stack trace: Sorry, cannot find error log Other information: Windows version. Does not occur with all images at all scales (!?), but does happen most of the time. Never occurs (??) in "pixels" mode.
Sounds somewhat similar to bug #514906. Looks like there is some bug in the 2.4.4 build that causes crashes when dialog windows are closed.
The crash does not occur when the dialog box closes; it occurs when the new tool is selected, either from the tool box or menu. I should have been more emphatic: this has never happened to me when the scale display is in the default "pixel" mode. Also, it is independent of the interpolation scheme.
Windows XP. Note: Locking X-Y or leaving X-Y unlocked does affect whether it crashes or not. After doing the scale action, crash can be avoided if user saves before selecting another tool (eg. Crop) GimpVS2008 (based on Gimp 2.4.4) does not crash with this scenario. FWIW: This crash can be replicated in Gimp 2.4.4 and Gimp 2.4.3 but does NOT occur with same actions in Gimp 2.4.2 or Gimp 2.4.1 bug #514906 - same pattern: no crash in Gimp 2.4.1, .2. crashes in Gimp 2.4.3, .4
What the fuck is GimpVS2008 ?
Sven, GimpVS2008 is the Gimp source compiled using Microsoft Visual C++ 2008. See http://www.gnomefiles.org/app.php?soft_id=2212 Alec and Sevendy, there is undoubtedly a problem, but it is almost impossible to figure out these sorts of crashes without a stack trace. Unfortunately, it is extremely difficult to get usable stack traces using the distributed version of Gimp for Windows -- so it's a bit of a quandry at the moment.
I have been able to reproduce this problem, exactly as described in the original report, on a dual-pentium laptop running Vista Business, with 2.4.4 set up using Tor's installer. I downloaded a tool called "Debug Diagnostics" from Microsoft, and after some struggling, managed to get a stack trace, although it's not very informative because of the lack of debugging info in the build. Still, it may give some hints, so I attach it below. One possibility, looking at the code via viewvc, is that the problem might have been caused by the changes to gdk_window_set_transient_for made on Jan 10 in order to fix bug #506769. But that's only a suggestion. Obviously if I could build Gimp on Windows myself, I would be able to say a lot more, but I'm a long way from being able to do that.
Created attachment 104891 [details] crappy stack trace
We need to know what version of GTK+ is included in the binary package that is being used here. Then we can reassign this report to GTK+.
Seems to be a duplicate of bug #506769. Fixed in GTK+ 2.12.6 and later. The installer currently has GTK+ 2.12.5. *** This bug has been marked as a duplicate of 506769 ***
*** Bug 523240 has been marked as a duplicate of this bug. ***