Tk Source Code

valgrind reports that test grid-10.39 produces:

==28020== 1 errors in context 1 of 204:
==28020== Conditional jump or move depends on uninitialised value(s)
==28020==    at 0x4FBB30: ResolveConstraints (tkGrid.c:1997)
==28020==    by 0x4FB38B: ArrangeGrid (tkGrid.c:1739)
==28020==    by 0x5EF6FF: TclServiceIdle (tclTimer.c:736)
==28020==    by 0x5C9748: Tcl_DoOneEvent (tclNotify.c:987)
==28020==    by 0x4F5A4A: Tk_UpdateObjCmd (tkCmds.c:1104)
==28020==    by 0x51C414: TclEvalObjvInternal (tclBasic.c:3727)
==28020==    by 0x583188: TclExecuteByteCode (tclExecute.c:2414)
==28020==    by 0x58122F: TclCompEvalObj (tclExecute.c:1535)
==28020== 
==28020== 
==28020== 2 errors in context 2 of 204:
==28020== Conditional jump or move depends on uninitialised value(s)
==28020==    at 0x4FBC3E: ResolveConstraints (tkGrid.c:2016)
==28020==    by 0x4FB3A0: ArrangeGrid (tkGrid.c:1740)
==28020==    by 0x5EF6FF: TclServiceIdle (tclTimer.c:736)
==28020==    by 0x5C9748: Tcl_DoOneEvent (tclNotify.c:987)
==28020==    by 0x4F5A4A: Tk_UpdateObjCmd (tkCmds.c:1104)
==28020==    by 0x51C414: TclEvalObjvInternal (tclBasic.c:3727)
==28020==    by 0x583188: TclExecuteByteCode (tclExecute.c:2414)
==28020==    by 0x58122F: TclCompEvalObj (tclExecute.c:1535)

When we [grid forget] a slave, its row and column values
get set to -1 to indicate that.

However, the layout calculation also uses row/col values of
-1 to indicate and imaginary space to the left/top of the layout
to simplify some algorithms.

These two meanings of -1 are colliding here.

This almost never happens, because by the time we reach
layout calculations, any slave in the grid is no longer
forgotten and has had its actual row/col value set.

**unless**

the attempt to set that row/col failed because it tried to
reach beyond the MAX_ELEMENT protection.  This is what grid-10.39
is testing.

A couple checks are added to avoid the collision.

Other aspects of this design that I question I leave untouched.

Fix committed for 8.5.18 and 8.6.4.