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

obsolete: 8.4.12
closed-out-of-date
8
2010-01-05
2006-04-14
Anonymous
No

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.

e.g.:

> 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
chawes@cadence.com

Discussion

  • Donal K. Fellows

    Logged In: YES
    user_id=79902

    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
    user_id=585068

    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
    user_id=996591

    Hi,

    tcl_platform:

    % 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
    %

    Backtrace:

    (gdb) bt
    #0 0xff3336f0 in TkWmDeadWindow (winPtr=0x526a0) at
    /home/chawes/installs/tcltk/tk8.4.12/unix/tkUnixWm.c:790
    #1 0xff26f624 in Tk_DestroyWindow (tkwin=0x526a0) at
    /home/chawes/installs/tcltk/tk8.4.12/generic/tkWindow.c:1441
    #2 0xff331788 in TkSendCleanup (dispPtr=0x3d2f8) at
    /home/chawes/installs/tcltk/tk8.4.12/unix/tkUnixSend.c:1281
    #3 0xff31dea0 in TkpCloseDisplay (dispPtr=0x3d2f8) at
    /home/chawes/installs/tcltk/tk8.4.12/unix/tkUnixEvent.c:174
    #4 0xff26d4ec in TkCloseDisplay (dispPtr=0x3d2f8) at
    /home/chawes/installs/tcltk/tk8.4.12/generic/tkWindow.c:281
    #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
    /home/chawes/installs/tcltk/tk8.4.12/generic/tkUtil.c:1093
    #7 0xff0fe400 in Tcl_Finalize () at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclEvent.c:803
    #8 0xff0fe038 in Tcl_Exit (status=0) at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclEvent.c:576
    #9 0xff0c1b48 in Tcl_ExitObjCmd (dummy=0x0, interp=0x21a78,
    objc=1, objv=0x225dc)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclCmdAH.c:658
    #10 0xff0b5c0c in TclEvalObjvInternal (interp=0x21a78,
    objc=1, objv=0x225dc, command=0x0, length=0, flags=0)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclBasic.c:3085
    #11 0xff101a60 in TclExecuteByteCode (interp=0x21a78,
    codePtr=0x101710)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclExecute.c:1419
    #12 0xff10000c in TclCompEvalObj (interp=0x21a78,
    objPtr=0x1079b0)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclExecute.c:981
    #13 0xff0b7758 in Tcl_EvalObjEx (interp=0x21a78,
    objPtr=0x1079b0, flags=131072)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclBasic.c:4049
    #14 0xff121e1c in Tcl_RecordAndEvalObj (interp=0x21a78,
    cmdPtr=0x1079b0, flags=131072)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclHistory.c:142
    #15 0xff121c48 in Tcl_RecordAndEval (interp=0x21a78,
    cmd=0x301e8 "exit\n", flags=131072)
    at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclHistory.c:62
    #16 0xff255f80 in StdinProc (clientData=0x67bb0, mask=2) at
    /home/chawes/installs/tcltk/tk8.4.12/generic/tkMain.c:368
    #17 0xff130888 in Tcl_NotifyChannel (channel=0x67bb0,
    mask=2) at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclIO.c:6904
    #18 0xff18c8a0 in FileHandlerEventProc (evPtr=0xffcf8,
    flags=-3) at
    /home/chawes/installs/tcltk/tcl8.4.12/unix/tclUnixNotfy.c:633
    #19 0xff14ebc0 in Tcl_ServiceEvent (flags=-3) at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclNotify.c:640
    #20 0xff14f1f0 in Tcl_DoOneEvent (flags=-3) at
    /home/chawes/installs/tcltk/tcl8.4.12/generic/tclNotify.c:945
    #21 0xff23eae8 in Tk_MainLoop () at
    /home/chawes/installs/tcltk/tk8.4.12/generic/tkEvent.c:1501
    #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
    /home/chawes/installs/tcltk/tk8.4.12/unix/tkAppInit.c:68
    (gdb)

    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.

    Thanks,
    Chris

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-31

    Logged In: YES
    user_id=72656

    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
    user_id=996591

    Just tried 8.4.13, the problem still exists there.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-31

    Logged In: YES
    user_id=72656

    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;
    break;
    }
    }

     
  • Chris Hawes

    Chris Hawes - 2006-05-31

    Logged In: YES
    user_id=996591

    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
    user_id=72656

    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