[Tcl-bugs] [ tcl-Bugs-733221 ] various memory leaks...

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

Bugs item #733221, was opened at 2003-05-06 05:07
Message generated for change (Comment added) made by mistachkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=733221&group_id=10894

Category: 40. Memory Allocation
Group: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Joe Mistachkin (mistachkin)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: various memory leaks...

Initial Comment:
--------

generic/tclDate.c

1. Shouldn't this file be using ckalloc/ckrealloc?
2. The following variables are allocated and are 
never freed:

int *TclDates;
YYSTYPE *TclDatev;

--------

win/tclAppInit.c, line 269:

    argSpace = (char *) Tcl_Alloc(
	    (unsigned) (size * sizeof(char *) + strlen
(cmdLine) + 1));

1. Shouldn't this also be ckalloc?
2. This is a local variable in the function.
3. This memory is never freed.

--------

tools/encoding/txt2enc.c

1. Memory allocated via malloc on line #181 and 
#204 is never freed.
2. Since this is a stand-alone utility, it should be 
fairly trivial to fix these leaks with the following 
code before "return 0" on line #243:

    for (hi = 0; hi < 256; hi++) {
	if (toUnicode[hi] != NULL) {
	    free(toUnicode[hi]);
            toUnicode[hi] = NULL;
	}
    }

--------

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. 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).

5. Another leak (see SF bug #731754, fixed in my 
patch #731356) involves this code, near line #279:

#ifdef WIN32
    TlsFree((DWORD) cachePtr);
#else
    free(cachePtr);
#endif

The above code is entirely incorrect for Win32.  I 
believe it should always be "free(cachePtr);" as 
cachePtr is NOT a TLS index, it is a block of 
memory.

6. Yet another leak (also fixed in my patch 
#731356) involves freeing the actual TLS index 
used by the threaded memory allocator (what the 
above incorrect code was TRYING and failing to do).

--------


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

>Comment By: Joe Mistachkin (mistachkin)
Date: 2003-05-10 01:34

Message:
Logged In: YES 
user_id=113501

I have fixed the tclAppInit.c leaks, the txt2enc.c leak, 
and tclThreadAlloc.c cachePtr leak.  I need some help 
(from JeffH ?) understanding the "style" of the threaded 
memory allocator to fix the remaining leaks in it.

The tclDate.c leaks totally confuse me as I have zero 
experience with yacc.  I'm of the opinion that these 
leaks should be plugged by creating a new finalization 
routine specific to the tclDate.c file 
called "TclFinalizeDate" or something like that.  

Also, this file should definately be calling 
ckalloc/ckrealloc and NOT mallco/realloc.  

However, I haven't the foggiest idea how to make 
yacc "do the right thing".


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=733221&group_id=10894