#1519 Bad winPtr->window pointer causes crash in Tk_GetHWND

obsolete: 8.4.3
closed-fixed
8
2004-05-08
2003-07-07
No

This is a somewhat obscure and intermitted crash,
demonstrated by the attached script which requires
Bryan Oakley's combobox implementation (demonstrated
with version 2.2.1). An access violation occurs when
WmProc() in tkWinWm.c gets called with a WM_ACTIVATEAPP
event. This isn't in the switch so it goes on to get
winPtr:

winPtr = GetTopLevel(hwnd);

Unfortunately, the value sometimes comes up bogus
(filled with bad pointers and such) and when it
subsequently calls Tk_GetHWND(winPtr), it crashes from
winPtr->window being a bad pointer when attempting to
get winPtr->window.handle.

After lots of experimentation, I was able to cause the
crash with a straight wish running the script (as
opposed to the extended wish plus other Tcl code for my
application, which originally seemed partly involved
due to the intermittent nature of the crash) .

For convenience I've made the buttons take up the huge
area of the main toplevel (.), but that doesn't matter
for demonstrating the crash -- it just keeps you from
having to move the mouse around a bunch. The crash
does, however, seem to involve some of the geometry
operations going on to center and size the various
windows, combined with the combobox and the window
icon. Commenting out any one of these *seems* to stop
the crash from happening, but since it's intermittent
it is hard to be sure. In case it matters, I'm also
attaching the icon I'm using.

To demonstrate, after launching the script, click the
button that says "Combo". A new toplevel will be
created, centered on the screen, with a combobox in it.
Close the window (click the [X] icon). It seems to
occur more often if you repeat this (click the "Combo"
button, close the window that pops up) a couple times.
Then click exit. Often, but not always, this will
crash (with an invalid page fault or an access
violation depending on whether or not
you're running wish from within DevStudio). After
rebuilding wish with debugging symbols and running from
DevStudio I was able to track the crash to the WmProc()
and Tk_GetHWND().

Discussion

  • Michael Kirkham

    Michael Kirkham - 2003-07-07

    Script demonstrating crash

     
  • Michael Kirkham

    Michael Kirkham - 2003-07-07
     
  • Michael Kirkham

    Michael Kirkham - 2003-07-07

    Logged In: YES
    user_id=498198

    Oh, one other probably important note: this was using Tcl/Tk
    8.4.3.

     
  • Don Porter

    Don Porter - 2003-07-07
    • milestone: --> obsolete: 8.4.3
    • priority: 5 --> 8
     
  • Michael Kirkham

    Michael Kirkham - 2003-07-09

    Logged In: YES
    user_id=498198

    Poking around with the VC++ debugger and Spy++, I've been
    able to figure out that the HWND receiving the
    WM_ACTIVATEAPP event is that of the transient toplevel for
    the combobox (that's displayed when you hit the little down
    arrow button to show the list). Sort of. Curiously, Spy++
    shows show TkToplevel's with the name I changed that
    transient to (instead of .top, for debugging). One with
    children, one without. It would seem that the problem is
    either some race condition, something is being left
    incomplete about the destruction of this transient toplevel
    when the toplevel containing the combobox is destroyed, or
    for some reason Tk creates two platform windows (perhaps a
    new window is created when certain reconfigurations take
    place?) and leaving the old one behind? Hmmm.. Here's what
    I see with my latest run:

    00000D48 "Blah Blah" TkTopLevel
    --00000D6C "*" TkChild
    ----00000CCC "*" TkChild
    ------00000CD0 "*" Static
    ------00000DA8 "*" TkChild
    00000D54 "combotopxxxx" TkTopLevel
    --00000D20 "*" TkChild
    ----00000CD4 "*" ScrollBar
    ----00000CC0 "*" ScrollBar
    00000D4C "combotopxxxx" TkTopLevel (this is the one crashing)
    00000D90 "TEST" TkTopLevel (this is the .exe i'm debugging)
    --00000D60 "*" TkChild
    ----00000CC8 "*" Button
    ----00000DA0 "*" Button
    00000DB0 "Console" TkTopLevel
    --00000DAC "*" TkChild
    ----00000D5C "*" ScrollBar
    ----00000D68 "*" TkChild

     
  • Michael Kirkham

    Michael Kirkham - 2003-07-09

    Logged In: YES
    user_id=498198

    More curious: altering the order of operations so that the
    combobox is added to the toplevel first, then it's centered,
    *then* the title and iconbitmap are set, results in the
    "cmbtopxxx" transient toplevel things not even being listed
    by Spy++ -and- it doesn't seem to crash that way. This
    leads me more strongly to think there might be some sort of
    race condition, perhaps in some combination of the these
    three things happening prior to the window being posted.

     
  • Joe Mistachkin

    Joe Mistachkin - 2003-09-16

    combobox extension 2.2.1

     
  • Michael Kirkham

    Michael Kirkham - 2003-09-16

    Logged In: YES
    user_id=498198

    I'm attaching the version of the combobox that I'm using.
    This is version 2.2.1 with a couple of minor changes for
    background color on non-editable entries, position of the
    list toplevel, and corrected order of withdrawing/making the
    toplevel transient, but these don't cause the crash to go
    away, nor are they the cause (the crash occurs with the
    actual 2.2.1 version).

     
  • Michael Kirkham

    Michael Kirkham - 2003-09-16

    Logged In: YES
    user_id=498198

    Oops. It didn't take my attachment, but mistachkin has
    added the real 2.2.1 version anyway.

     
  • Michael Kirkham

    Michael Kirkham - 2003-09-17

    Script demonstrating crash without combobox

     
  • Michael Kirkham

    Michael Kirkham - 2003-09-17

    Logged In: YES
    user_id=498198

    New file ccrash2.tcl, which demonstrates the crash without
    the need for the combobox widget. Just run it, it'll flash
    a bit as it creates and destroys toplevels, and it should
    crash after a short period of time. No interaction necessary.

    The order of the withdrawl on $hWnd2 doesn't seem to matter.
    Commenting out any one of the following (seems to) prevent
    the crash:

    1. Commenting out the wm override on $hWnd in proc centerWin.
    2. Commenting out the wm iconbitmap call.
    3. Commenting out the wm override on $hWnd2 in proc booom.
    4. Commenting out the wm transient on $hWnd2 in proc booom.

    This can possibly be pared down even more, but the crash
    seems to be the result of a race condition set up by the
    combination of the above four things.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2003-10-13

    Logged In: YES
    user_id=72656

    I can't get this to crash on XP. I had to modify ccrash2.tcl
    to use the tk.ico from the distro and the tai-ku.gif image in
    $tk_library/images/.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2003-10-13
    • status: open --> open-works-for-me
     
  • Michael Kirkham

    Michael Kirkham - 2003-10-13

    Logged In: YES
    user_id=498198

    FWIW, my tests are running on a 200 MHz Pentium Pro running
    Win98. Since it seems to be a race condition, timing could
    be crucial. The image create call is not necessary and can
    be deleted (but not the wm iconbitmap). Adding an "update
    idletasks" call as the very first thing that the centerWin
    proc does (before the wm withdraw) causes the crashing to stop.

     
  • Akhilesh Dwivedi

    Logged In: YES
    user_id=600123

    combocrash.tcl is still crashing on Windows XP. I have used
    Windows XP SP1 on P-III 730mHZ and 512 MB of RAM. Also
    tested with 8.4.6 and 8.5a1 and found the crash.
    But ccrash2.tcl is not crashing on XP.

    Does anybody have a resolution?

     
  • Chengye Mao

    Chengye Mao - 2004-05-08

    Logged In: YES
    user_id=191079

    This bug was caused by incorrectly handling and destroying
    an older wrapper in function UpdateWrapper of tkWinWm.c.
    It may generate dangling windows (old wrappers) which will
    be destroyed at last and cause invalid access by
    Tk_GetHWND. This is a generic bug since Tk8.0. Any tk wm
    functions that call UpdateWrapper may cause the same
    problem, resuling in wish crash during exiting time. Many
    other reported wish crashes during exit may also be caused
    by this same bug.

     
  • Chengye Mao

    Chengye Mao - 2004-05-08
    • status: open-works-for-me --> closed-fixed
     
  • Michael Kirkham

    Michael Kirkham - 2004-05-11

    Logged In: YES
    user_id=498198

    Just noting that I tested the fix and it works for me (i.e.,
    no longer crashing). Thanks.

     

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

Sign up for the SourceForge newsletter:





No, thanks