Tcl Source Code

generic/tclThreadAlloc.c 

1. We have the static file variables: 

static Tcl_Mutex *listLockPtr; 
static Tcl_Mutex *objLockPtr; 

2. They are allocated via TclpNewAllocMutex, which 
BOTH allocates memory via malloc AND calls 
InitializeCriticalSection on the contained critical 
section. 

3. Neither the block of memory nor the critical 
section are ever freed. 

4. This applies to the above static variables and 
to any other mutexes allocated via 
TclpNewAllocMutex.

5. There needs to be a new function in 
tclThreadAlloc.c, 
called "TclFinalizeThreadAllocSubsystem", that 
frees these mutexes (probably by calling an 
appropriate platform specific func, yet to be 
created, perhaps called "TclpNewFreeMutex") and 
then calls the "TclpFinalizeThreadAllocSubsystem" 
function for the platform specific cleanup (i've 
created the Win32 version of this function in my 
new patch #731356). 

6. Yet another leak involves freeing the actual TLS 
index used by the threaded memory allocator.

File Added - 94637: 736426-8.5.patch

Logged In: YES 
user_id=72656

Attached is the patch applied for 8.5-head.

File Deleted - 94624:

File Added - 94635: 736426-8.4.patch

Logged In: YES 
user_id=72656

Attached is the patch applied for 8.4.

Logged In: YES 
user_id=72656

The use of PTHREAD_ONCE_INIT in FreeKey is invalid on HP and
Solaris, where it is a struct.  This conflict needs to be
resolved because it's central to reinitialization.

File Deleted - 94071: 



File Added - 94624: 736426-8.4.patch

Logged In: YES 
user_id=99768

Backported for 8.4 - patch attached

File Added - 94096: bug736426.diff

Logged In: YES 
user_id=113501

Ok, this time with feeling.  Here is an updated patch (based
on kbk's) that includes cleanup of the Unix pthread key as well.

This should fix all known memory/resource leaks in the
threaded memory allocator and make it possible for it to be
re-initialized properly if Tcl is unloaded and reloaded into
a process (such as a browser).

File Deleted - 94054:

File Added - 94071: 736426.patch

Logged In: YES 
user_id=99768

Revised patch attached; corrects several compilation problems
on Win2k/VC++6.

File Added - 94054: bug736426.diff

Logged In: YES 
user_id=113501


This patch should fix all the remaining leaks in the
threaded memory allocator.  Please review.

Logged In: YES 
user_id=113501

from CVS HEAD (the leak is in TclpGetAllocCache):

 200 bytes in 1 blocks are definitely lost in loss record 12
of 41
    at 0x3C0250D5: malloc (in
/usr/local/lib/valgrind/vgpreload_memche$
    by 0x3C0FC720: (within /usr/local/lib/valgrind/libc_r.so.4)
    by 0x3C0FEFE9: (within /usr/local/lib/valgrind/libc_r.so.4)
    by 0x3C0FF179: pthread_key_create (in
/usr/local/lib/valgrind/libc$
    by 0x3C0BFF9B: (within ./libtcl8.5.so)
    by 0x3C0FF800: pthread_once (in
/usr/local/lib/valgrind/libc_r.so.$
    by 0x3C0BFFDD: TclpGetAllocCache (in ./libtcl8.5.so)
    by 0x3C0AC485: TclpAlloc (in ./libtcl8.5.so)
    by 0x3C04F550: Tcl_Alloc (in ./libtcl8.5.so)
    by 0x3C0BFAB1: Tcl_MutexLock (in ./libtcl8.5.so)
    by 0x3C09A712: TclInitObjSubsystem (in ./libtcl8.5.so)     
    by 0x3C070CB9: TclInitSubsystems (in ./libtcl8.5.so)
    by 0x3C06DE97: Tcl_FindExecutable (in ./libtcl8.5.so)
    by 0x3C093E78: Tcl_Main (in ./libtcl8.5.so)
    by 0x8048632: main (in ./tclsh)

also from CVS HEAD (mutexes allocated by TclpNewAllocMutex
are never freed, there are a lot of these):

 132 bytes in 11 blocks are still reachable in loss record
11 of 41
    at 0x3C0250D5: malloc (in
/usr/local/lib/valgrind/vgpreload_memche$
    by 0x3C0FC720: (within /usr/local/lib/valgrind/libc_r.so.4)
    by 0x3C0FDCAE: pthread_mutex_init (in
/usr/local/lib/valgrind/libc$
    by 0x3C0BFF68: TclpNewAllocMutex (in ./libtcl8.5.so)
    by 0x3C0AC2F8: (within ./libtcl8.5.so)
    by 0x3C0AC490: TclpAlloc (in ./libtcl8.5.so)
    by 0x3C04F550: Tcl_Alloc (in ./libtcl8.5.so)
    by 0x3C0BFAB1: Tcl_MutexLock (in ./libtcl8.5.so)
    by 0x3C09A712: TclInitObjSubsystem (in ./libtcl8.5.so)
    by 0x3C070CB9: TclInitSubsystems (in ./libtcl8.5.so)
    by 0x3C06DE97: Tcl_FindExecutable (in ./libtcl8.5.so)
    by 0x3C093E78: Tcl_Main (in ./libtcl8.5.so)
    by 0x8048632: main (in ./tclsh)

Logged In: YES 
user_id=79902

I was just style-fixing.  I know nothing about how to fix
these problems.

Logged In: YES 
user_id=113501


This bug appears to still be in HEAD.  Assigning to dkf 
because he touched it last.

Logged In: YES 
user_id=113501

The issue is NOT with NT4. This bug (and a couple other 
related ones) demonstrate design flaws in the threaded 
memory allocator.

I am more than willing to help fix these problems, however, I 
am lacking information about the original intent of some 
aspects of the design, as I have mentioned previously.

Logged In: YES 
user_id=72656

NT4 is no longer a supported OS.  Please create one that can 
be reproduced on 98, 2000 or XP.

Logged In: YES 
user_id=113501

I can now easily reproduce a crash in the latest Tcl/Tk 
regarding this issue (limited number of TLS indexes per 
process).

The cause is that Tcl/Tk doesn't think that anybody else in 
the process is going to be using TLS indexes, which is 
definitely NOT the case.

Tcl (especially with Tk) very very rapidly runs out of TLS 
indexes for even trivial Tk scripts.

I can write a simple C app that uses Tcl/Tk and allocates 
about half of the available TLS indexes on NT4 to 
demonstrate.