Tk Source Code

In tkOption.c:SetupStacks (lines 1343-1374 v1.18) there is a free memory read. I'm not familiar with this code so I don't fancy checking it in and haven't done so before.

The cause appears to be access to system stacks element pointers that have been reallocated within the same loop the pointer was assigned.

I tried the following changes and it prevented the free memory read and there was no noticeable strangeness happening in my fairly complex GUI:

Changed section in tkOption.c:SetupStacks:

    for (iPtr = searchOrder; *iPtr != -1; iPtr++) {
register Element *elPtr;
int count, current; /* current added */
Tk_Uid id;

i = *iPtr;
if (i & CLASS) {
    id = winPtr->classUid;
} else {
    id = winPtr->nameUid;
}
#if 0 /* removed */
elPtr = tsdPtr->stacks[i]->els;
count = levelPtr->bases[i];
#endif
        current = 0; /* current added */
count = tsdPtr->stacks[i]->numUsed; /* count initialised from current stacks */

/*
 * For wildcard stacks, check all entries;  for non-wildcard
 * stacks, only check things that matched in the parent.
 */

if (!(i & WILDCARD)) {
#if 0 /* removed */
    elPtr += levelPtr[-1].bases[i];
#endif
            current = levelPtr[-1].bases[i]; /* I think level above should not change in this loop */
    count -= current;
}
        /* Always get elPtr anew after ExtendStacks() is called. */
for ( elPtr = tsdPtr->stacks[i]->els + current; count > 0;
              current++, elPtr = tsdPtr->stacks[i]->els + current, count-- ) {
    if (elPtr->nameUid != id) {
continue;
    }
    ExtendStacks(elPtr->child.arrayPtr, leaf);
}
    }


It didn't fix my crash, but hey that's life.

Serhiy, many thanks for fixing this very long-standing bug! Merged into main, core-9-0-branch, and core-8-6-branch by commits [6043b105], [e047308b], and [7a4d8176].

I encountered the same problem during test ttk-coreoptions-combobox for a -DPURIFY build of recent Tcl/Tk 9.1 on macOS 15 (Intel). The fix proposed by Serhiy works for me.

Still present. ExtendStacks() appends the children of a matching node to the stacks, and if a child has the same type as the stack being scanned (e.g. *Frame*Button*opt, both class wildcard nodes), it can reallocate that stack, and the loop continues with the pointer to the freed array. Usually this goes unnoticed because the freed memory is not reused yet.

Proposed fix in branch option-stack-realloc, with test option-17.1.