#912 Tk commands callable before Tk_Init bombs accessing Tcl stub table

obsolete: 8.3.1

OriginalBugID: 5494 Bug
Version: 8.3.1
SubmitDate: '2000-05-15'
LastModified: '2000-05-15'
Severity: SER
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
RelatedBugIDs: 2269
OS: All Windows

Per Mildner

There are Tk_ routines that can reasonably be called before Tk_Init (and thus Tcl_InitStubs) is called. In particular Tk_GetNumMainWindows (should return zero) and Tk_MainWindow (explicitly documented as callable on non-Tk interpreters), perhaps there are more.

When Tk is built using TCL stubs (always the case on Windows) these routines will crash while trying to access Tcl_GetThreadData trough the (NULL) Tcl stub table.

The patch for Bug DB ticket#2269 solves this problem in another context and could be adapted. (explicitly check for tclStubsPtr==NULL)


  • Donal K. Fellows

    • priority: 5 --> 8
  • Don Porter

    Don Porter - 2001-03-27
    • labels: 104343 --> 63. Tk_Win Functions
  • Don Porter

    Don Porter - 2001-11-29
    • assigned_to: nobody --> hobbs
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-12-28
    • assigned_to: hobbs --> dgp
    • priority: 8 --> 5
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-12-28

    Logged In: YES

    While it notes that Tk_MainWindow can be called on non-Tk
    interpreters, it doesn't explicitly say it can be called
    before Tk has been initialized. In fact, I don't seem to
    see that for any function. If you look at bug #219996,
    which is the source of the above mentioned (with patch in
    #220542), the cause is harder to avoid because the Tk dll
    just has to exist and it blows on dll unload. Referring
    this to dgp as he was working on this before, and can
    comment on the validity here.

  • Don Porter

    Don Porter - 2001-12-28

    Logged In: YES

    Looking this over, I think the submitter is correct.
    There are some Tk_* routines that one may want/need
    to call before calling Tk_Init on any interp. Those
    routines should work (or at least return a sensible
    error message instead of crashing) before Tcl stubs
    have been initialized.

    Most Tk_* routines -- that operate on an interp assumed
    to have Tk loaded in it -- do not need this capability.

    This issue should only arise when one writes his own
    "big wish" application, and does not make use of Tk_Main().

    A possible workaround would be for someone needing this
    to build a copy of Tk without -DUSE_TCL_STUBS. Only
    folks coding in C need this, and they have the ability
    to build their own Tk libraries from source in such a way
    that they don't need it anymore.

    Next step would be to compose a list of the Tk_* routines
    needing this improvement.

  • Don Porter

    Don Porter - 2001-12-28

    Logged In: YES

    On second thought, the workaround really won't help
    if one distributes a "big wish" program to another
    user on another machine expecting it will pick up
    the locally installed tk83.dll file.

  • Don Porter

    Don Porter - 2002-02-01
    • assigned_to: dgp --> hobbs
  • Don Porter

    Don Porter - 2002-02-01
  • Don Porter

    Don Porter - 2002-02-01

    Logged In: YES

    Here's a patch. Note that it's not possible to
    get exactly what's documented for Tk_MainWindow.
    If Tk_Init() has not been called on any interpreter,
    so that Tk has not called Tcl_InitStubs to initialize
    its own copy of the Tcl stub stable, then it has no
    access to routines that can set the result in the interp.
    Thus, Tk_MainWindow can only return NULL; it cannot
    return an error message as documented.

    We've really got much better ways of testing whether
    Tk is loaded in an interp now, anyway.
    Tcl_PkgPresent(interp, "Tk", ...).

    This patch is really about turning crashes into errors,
    not about enabling any useful programming practices.

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-02-27
    • status: open --> closed-fixed
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-02-27

    Logged In: YES

    added patch to 8.4a4cvs and closing re dgp's remarks.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks