#1259 unmap crash in PackReqProc(), tkPack.c

[Anonymous]

I'm using the C interface, on win-32. I'm using mostly
script calls (Tcl_Eval) but some Tk library calls where
necessary.

When a Tk dialog is being unmapped, I crash in
PackReqProc(), tkPack.c. This happens if I have made
the dialog a "transient" to another dialog. If the dialog is
not a transient, it can be unmapped without crashing.
The unmapping is being done totally under script control.

On line 482 in tkPack.c, PackReqProc(), it is casting
the clientData into packPtr. But packPtr->masterPtr
(next line of code) is 0xddddddd (probably not what the
author had in mind!).

The call stack makes me think we shouldn't even be
going down this far - it looks like the dialog has already
been unmapped but we keep running until we get down
to PackReqProc(). Here's the call stack:

PackReqProc()
Tk_GeometryRequest()
ArrangeGrid()
TclServiceIdle()
Tcl_ServiceAll()
TkWinChildProc()
USER32!
USER32!
USER32!
USER32!
NTDLL!
Tk_UnmapWindow() line 1733: XUnmapWindow

As I follow the Tk_UnmapWindow() calling down
ultimately to Tk_GeometryRequest(), I get confused by
all the cast and nested pointers so I'm afraid I can't offer
more insight...

Why would we be packing something that's already
been unmapped - Can we assume that NTDLL and
USER32 are busy trashing the window, following the
XUnmapWindow call?

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

This may be pilot error. Perhaps something was free that
should be Tcl_EventuallyFree'd, or not properly preserved.
With masterPtr == 0xdddddddd it usually means that it was
null'ed out or freed already.

[jesse newcomb]

Logged In: YES
user_id=591432

I am only using C-library for Tk_PathName(), all other Tk
interaction is done through Tcl_Eval() so I would assume
things are clean / high-level.

This "could be" pilot error (I'm new to Tcl/Tk). But I filed this
in hopes that something could at least be done to make it
crash-proof. I know my code is not doing any free-ing (no Tk
or Tcl library calls other than Tk_PathName()), it seems odd
that Tk_UnmapWindow() would call down into something that
would crash because the window had already been destroyed.

I'm able to work around this by just "don't do that" as the
doctor said.