[Tcl-bugs] [ tktoolkit-Bugs-614325 ] Tk crash upon Tcl_DeleteInterp...

[<no...@so...>]

Bugs item #614325, was opened at 2002-09-25 03:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=614325&group_id=12997

Category: 74. Application Embedding
Group: = 8.4.0
Status: Pending
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tk crash upon Tcl_DeleteInterp...

Initial Comment:
The problem [apparently] stems from having no 
main windows upon entering the following routine 
at the bottom of this report.  The "dispPtr" local 
variable is set to the result of a function.  The 
resulting pointer is NOT checked for a NULL value 
prior to dereferencing the pointer in the IF 
statement that follows.  At some point, the 
assumption might have been made that there 
would always be a main window???

void
Tk_FreeGC(display, gc)
    Display *display;		/* Display for which 
gc was allocated. */
    GC gc;			/* Graphics context 
to be released. */
{
    Tcl_HashEntry *idHashPtr;
    register TkGC *gcPtr;
    TkDisplay *dispPtr = TkGetDisplay(display);

    if (!dispPtr->gcInit) {
	panic("Tk_FreeGC called before 
Tk_GetGC");
    }
    if (dispPtr->gcInit < 0) {
	/*
	 * The GCCleanup has been called, and 
remaining GCs have been
	 * freed.  This may still get called by 
other things shutting
	 * down, but the GCs should no longer be 
in use.
	 */
	return;
    }

--
JJM


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-09 14:25

Message:
Logged In: NO 

#614325 and #649209...

Ok.  I have found the fundamental problem(s) here.  

Tk_FreeGC upon entry calls TkGetDisplay.  TkGetDisplay 
upon entry fetches it's ThreadSpecificData.  It then tries 
to search the list of main windows for the specified 
display.  

However, the problem in this case, is "deeper" down.  
The problem is that the dataKey being relied upon by 
TkGetDisplay is destroyed and recreated, destroying 
along with it all the vital state information it held.  

It is destroyed by Tcl_FinalizeThread, which calls 
TclFinalizeThreadData.  In threaded builds, this should 
NOT be a problem, since thread local storage is 
automatically keyed off of the thread in addition to the 
keyPtr (slot number).  However, for non-threaded 
builds, the consequences are totally disastrous.  

Another related problem that I ran into is that the 
internal data structures for the "simulated" thread local 
storage are not protected by any locking mechanism.  I 
realize that this is by design for non-threaded builds.  
However, since Tcl's "thread-safety protocol" suggests 
that you can always use Tcl interpreters from the thread 
they are created on without mentioning any 
other "gotchas", I think the code should be changed to 
reflect that (via a process wide mutex, in this case).

The "solution" is either to force people to use threaded 
builds or to re-implement the "simulated" thread local 
storage to key off of the current thread id in addition to 
the passed in "key" value.  

JJM


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-12-07 14:05

Message:
Logged In: YES 
user_id=72656

This may be related to bug 649209.  If so, please alert me 
and I will raise the prio.

----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2002-12-07 01:46

Message:
Logged In: YES 
user_id=113501

This bug may not be closed...

I'm going to be working on it this weekend.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-08 06:26

Message:
Logged In: NO 

NOT A BUG in Tk...

After some work, I realized I was calling the Tcl/Tk C 
API incorrectly (from the wrong thread).

JJM


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-08 03:11

Message:
Logged In: NO 

I can now duplicate this bug on Windows 2000 with a 
high degree of reliability.

Additionally, this problem no longer appears to be 
related to having no main window.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-25 04:46

Message:
Logged In: NO 

Here is the call stack associated with this crash:

Tk_FreeGC(_XDisplay * 0x049a3418, XGCValues * 
0x04220c10) line 300
Tk_Free3DBorder(Tk_3DBorder_ * 0x04220ac0) line 452 
+ 16 bytes
FreeResources(TkOption * 0x041f9130, Tcl_Obj * 
0x00000000, char * 0x04220810, Tk_Window_ * 
0x041fa680) line 1756 + 11 bytes
Tk_FreeConfigOptions(char * 0x042207e0, 
Tk_OptionTable_ * 0x041f8a10, Tk_Window_ * 
0x041fa680) line 1661 + 21 bytes
DestroyFramePartly(Frame * 0x042207e0) line 889 + 22 
bytes
FrameCmdDeletedProc(void * 0x042207e0) line 1725 + 
9 bytes
Tcl_DeleteCommandFromToken(Tcl_Interp * 
0x041d7188, Tcl_Command_ * 0x042208c0) line 2460 
+ 13 bytes
TclTeardownNamespace(Namespace * 0x041e3490) line 
804 + 13 bytes
DeleteInterpProc(Tcl_Interp * 0x041d7188) line 990 + 
12 bytes
Tcl_EventuallyFree(void * 0x041d7188, void (char *)* 
0x048f1138 DeleteInterpProc(Tcl_Interp *)) line 313 + 7 
bytes
Tcl_DeleteInterp(Tcl_Interp * 0x041d7188) line 928 + 
14 bytes


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=614325&group_id=12997