GNOME Bugzilla – Bug 313922
Crash doubleclicking in move tool with floating selection
Last modified: 2005-08-20 12:36:11 UTC
Distribution/Version: ubuntu Load an xcf that has lots of layers (though I'm not sure if that's important). Copy something, perhaps one of the layers. Paste it, and leave it as a floating layer. Select the move tool. Doubleclick on the floating layer. (Which happens to me when I try to move the layer and my finger slips on the mouse button, causing an accidental second click.) GIMP either crashes, or hangs (including hanging X). I see a hang when I run gimp from the cmdline and doubleclick; I see a crash when I run from the windowmanager menus and click-drag-slip-secondclick. If I get to a console and attach gdb to it, I get: [ ... ]
+ Trace 62543
Notice draw_tool=0x0, bound_segs=0x0 even though n_bound_segs=4 in #17. It's trying to loop over that null bound_segs. But if draw_tool == 0x0, why does the g_return_if_fail (GIMP_IS_DRAW_TOOL (draw_tool) at the beginning of the function not protect it? I don't actually understand why the GIMP_IS_DRAW_TOOL check fails (I even tried a check for draw_tool == 0 at the beginning of the function, and that's failing too, so maybe it's somehow getting zeroed later?) but I can see why the other check isn't working: it's backward. Maybe the clause used to be an if and wasn't reversed when it was changed to g_return_if_fail. I changed it to two separate checks: g_return_if_fail (n_bound_segs > 0); g_return_if_fail (bound_segs != NULL); and I no longer see the crash/hang.
Fix checked in.
Reopening because the patch just fixed the resulting crash, the actual bug is still there and probably hides somewhere in boundary.c
Fixed in CVS: 2005-08-20 Michael Natterer <mitch@gimp.org> * app/base/boundary.c (sort_boundary): look at the passed "ns" variable instead of at the global "num_segs" one to figure if the passed array of BoundSegs is empty. Fixes bug #313922 at its root.
For the records: 2005-08-20 Michael Natterer <mitch@gimp.org> * app/base/boundary.c: moved the entire internal state of boundary creation and simplification from <eek>global variables</eek> to a new "Boundary" struct that needs to be newly allocated for each boundary. Yes this allocates and frees memory more often than before but the old code was simply one big eek.