#2054 Wish core dumps when DISPLAY set to :<n>

obsolete: 8.4.12

Running Tk 8.4.12 on a Solaris 5.8 machine and trying
to display to a vncserver running locally as display :1.0.

When my DISPLAY environment variable is set to :1.0,
wish core dumps upon exit with this error message:

"called Tcl_FindHashEntry on deleted table"

If DISPLAY is set to <hostname>:1.0, this core dump
does not happen. It seems to only happen when the
hostname is not explicitly set in the DISPLAY variable.


> setenv DISPLAY :1.0
> wish
% exit
called Tcl_FindHashEntry on deleted table
Abort (core dumped)
> setenv DISPLAY machinename:1.0
> wish
% exit
(no core file)

Any help would be appreciated. Thanks.
Chris Hawes


  • Donal K. Fellows

    Logged In: YES

    Guessing the category, but that's probably wrong :-(
    Given that most people omit the display, this isn't a
    release-blocker for 8.4.13, but ought to be fixed ASAP anyway.

  • Donal K. Fellows

    • labels: --> 67. Unix Window Operations
    • milestone: --> obsolete: 8.4.12
    • priority: 5 --> 8
    • assigned_to: nobody --> hobbs
  • Nobody/Anonymous

    Logged In: NO

    HP-UX 11, wish8.3
    --> bad screen number "0"

  • Anonymous - 2006-05-30

    Logged In: YES

    I've been reviewing the paths with cscope involving 1470524
    and the problem isn't apparent in the code. I also made a
    build of 8.4.12 linking wish8.4 with libefence.a and found
    no problems with the same test case.

    So I think it's definitely something weird with that Solaris
    system's XOpenDisplay or possibly Tcl's threading. We need
    more information.

    Can you provide the output of:
    parray tcl_platform

    If possibly please also get a backtrace by doing this:
    mkdir debug_bld
    cd debug_bld
    ../tcl8.4.12/unix/configure --enable-symbols=all
    setenv DISPLAY :1.0
    make shell

    You should have a core file by this point.
    Then run:
    gdb wish wish.core (note wish.core may be named core)

    At the gdb prompt type backtrace.

    Note: there is also a ddb or db (debugger) I think that
    comes with Solaris. I don't have such a tool available, so
    consult the documentation. The backtrace from the core
    generated by the abort() should be very useful in tracking
    this down.

  • Chris Hawes

    Chris Hawes - 2006-05-31

    Logged In: YES



    % parray tcl_platform
    tcl_platform(byteOrder) = bigEndian
    tcl_platform(machine) = sun4u
    tcl_platform(os) = SunOS
    tcl_platform(osVersion) = 5.8
    tcl_platform(platform) = unix
    tcl_platform(user) = chawes
    tcl_platform(wordSize) = 4


    (gdb) bt
    #0 0xff3336f0 in TkWmDeadWindow (winPtr=0x526a0) at
    #1 0xff26f624 in Tk_DestroyWindow (tkwin=0x526a0) at
    #2 0xff331788 in TkSendCleanup (dispPtr=0x3d2f8) at
    #3 0xff31dea0 in TkpCloseDisplay (dispPtr=0x3d2f8) at
    #4 0xff26d4ec in TkCloseDisplay (dispPtr=0x3d2f8) at
    #5 0xff27171c in DeleteWindowsExitProc (clientData=0x386f0)
    at /home/chawes/installs/tcltk/tk8.4.12/generic/tkWindow.c:2767
    #6 0xff26c100 in TkFinalize (clientData=0x0) at
    #7 0xff0fe400 in Tcl_Finalize () at
    #8 0xff0fe038 in Tcl_Exit (status=0) at
    #9 0xff0c1b48 in Tcl_ExitObjCmd (dummy=0x0, interp=0x21a78,
    objc=1, objv=0x225dc)
    #10 0xff0b5c0c in TclEvalObjvInternal (interp=0x21a78,
    objc=1, objv=0x225dc, command=0x0, length=0, flags=0)
    #11 0xff101a60 in TclExecuteByteCode (interp=0x21a78,
    #12 0xff10000c in TclCompEvalObj (interp=0x21a78,
    #13 0xff0b7758 in Tcl_EvalObjEx (interp=0x21a78,
    objPtr=0x1079b0, flags=131072)
    #14 0xff121e1c in Tcl_RecordAndEvalObj (interp=0x21a78,
    cmdPtr=0x1079b0, flags=131072)
    #15 0xff121c48 in Tcl_RecordAndEval (interp=0x21a78,
    cmd=0x301e8 "exit\n", flags=131072)
    #16 0xff255f80 in StdinProc (clientData=0x67bb0, mask=2) at
    #17 0xff130888 in Tcl_NotifyChannel (channel=0x67bb0,
    mask=2) at
    #18 0xff18c8a0 in FileHandlerEventProc (evPtr=0xffcf8,
    flags=-3) at
    #19 0xff14ebc0 in Tcl_ServiceEvent (flags=-3) at
    #20 0xff14f1f0 in Tcl_DoOneEvent (flags=-3) at
    #21 0xff23eae8 in Tk_MainLoop () at
    #22 0xff255cc0 in Tk_MainEx (argc=-1, argv=0xffbef4c8,
    appInitProc=0x108f8 <Tcl_AppInit>, interp=0x21a78)
    at /home/chawes/installs/tcltk/tk8.4.12/generic/tkMain.c:297
    #23 0x000108e4 in main (argc=1, argv=0xffbef4c4) at

    I noticed that with the debug build I don't get the "called
    Tcl_FindHashEntry on deleted table" message, and the
    backtrace looks a bit different after the Tk_DestroyWindow
    call (I can attach this if you want).

    Let me know if this gives you any clues and what else I can
    do to help.


  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-31

    Logged In: YES

    Can you please retry this with 8.4.13 or the 8.4 CVS head.

  • Chris Hawes

    Chris Hawes - 2006-05-31

    Logged In: YES

    Just tried 8.4.13, the problem still exists there.

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-31

    Logged In: YES

    What is the stack trace in 8.4.13? I ask because line 790
    in tkUnixWm.c doesn't point to a line that could possibly
    cause a crash:

    for (prevPtr = (WmInfo *) winPtr->dispPtr->firstWmPtr; ;
    prevPtr = prevPtr->nextPtr) {
    if (prevPtr == NULL) {
    Tcl_Panic("couldn't unlink window in TkWmDeadWindow");
    790: if (prevPtr->nextPtr == wmPtr) {
    prevPtr->nextPtr = wmPtr->nextPtr;

  • Chris Hawes

    Chris Hawes - 2006-05-31

    Logged In: YES

    The stack trace is the same as with 8.4.12, pointing to the
    same line of code that you outlined. Odd. I played around
    with it a bit but didn't find anything that seemed significant.

    I did run wish with purify and there are some free memory
    reads/writes right before the crash, occurring at
    tkWindow.c:1344, tkUnixWm.c:780, and tkUnixWm.c:785. When
    DISPLAY is set to <hostname>:1.0 there are none at all.

    I haven't had a chance to investigate any further than that
    and I know this is not much to go on but maybe it will
    provide a clue for something else I can look into?

    I will try to take a closer look as soon as I get a chance.

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-06-01

    Logged In: YES

    Those spots would indicate that we are touching a dispPtr
    that has already been disposed of. I simply can't repro
    this bug on an x86 machine either. My Solaris machine is a
    bit more limited in the software installed.

  • Pat Thoyts

    Pat Thoyts - 2010-01-05
    • status: open --> closed-out-of-date
  • Pat Thoyts

    Pat Thoyts - 2010-01-05

    Non reproducible on anything current and platform specific to an ancient platform.


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

Sign up for the SourceForge newsletter:

No, thanks