Memory leaks and other problems

From: Murrgon (murrgon_at_hotmail.com)
Date: 11/28/03 

Date: Fri, 28 Nov 2003 11:37:07 -0500

I have downloaded the most recent version of the source code
(8.4.5) and I wrote a very simple test app:

#include <Windows.h>
#include <StdIo.h>
#include "TCL.h"

int main()
{
   Tcl_Interp* pTCLInterpreter = NULL;
   pTCLInterpreter = Tcl_CreateInterp();
   if (pTCLInterpreter)
   {
     int nResult = Tcl_Eval(pTCLInterpreter, "puts \"Hello World\"");
     if (TCL_OK != nResult)
       printf("TCL command failed\n");

     Tcl_DeleteInterp(pTCLInterpreter);
     pTCLInterpreter = NULL;
   }

   return(0);
}

As you can see I am running this on a windows machine. I have
built the static version of TCL from the win directory from the
source and I am linking with the resulting tcl84xx.lib.

Just for the heck of it I decided to run my little test program
through BoundsChecker (v7.0). I was remiss to discover that TCL
is doing some things that are causing leaks.

First, and probably most important, tclWinConsole.c is creating
threads using the CreateThread() function. This will cause
memory leaks when the created thread uses the C runtime.

MSDN quote:
"A thread that uses functions from the C run-time libraries
should use the beginthread and endthread C run-time functions
for thread management rather than CreateThread and ExitThread.
Failure to do so results in small memory leaks when ExitThread
is called."

Actually TCL should be using beginthreadex() as that is what
CreateThread() is using and the value returned from
beginthreadex() is compatible with all of the ThreadAPI
functions (like ResumeThread() for example).

I was also looking at the Tcl_WinTCharToUtf() function (and its
opposite). I did some digging and disovered that the
TclpSetInitialEncodings() function is calling
TclWinSetInterfaces() to set up the UNICODE vs ANSI encodings.
However it is using the 'platformId == VER_PLATFORM_WIN32_NT'
expression to determine if it should be using UNICODE or not.

Last time I checked there was no *requirement* that all apps
running on an NT based OS had to run using UNICODE. In fact
it is very easy to create a program in NT that doesn't have
anything to do with UNICODE. NT based OSes *support* UNICODE
(whereas Win9x and ME do not, at least not without add-ons)
but it does not mean that a particular program actually uses
it. The TCHAR type is compile-time defined according to
the -DUNICODE macro so any application can be built one way
or the other. It seems rather odd that TCL would decide that
a TCHAR will be 16 bits if we are running on NT.

Murrgon

Quantcast