Pointer/Memory Leak

[Chris]

Hope you guy can give answer my problem.

void functiona (HWND hWnd)
{
   char *lpszMesage=NULL;
   char *lpszTmp=NULL;
   char *lpszPtr=NULL;

   lpszMessage = new char[14];
   strcpy(lpszMessage, "1234567890..."); 
   lpszPtr = lpszMessage
   lpszPtr++;   
   MessageBox(hWnd, lpszPtr, "Data #1", MB_OK);
   lpszTmp = new char[10];
   strcpy(lpszTmp, "123456789");
   lpszPtr = lpszPtr + 5;       
   lpszPtr = lpszTmp;
   MessageBox(hWnd, lpszPtr, "Data #2", MB_OK);
   delete [] lpszTmp;
   delete [] lpszMessage;
} 

I notice that there will be 4Bytes of memory leak on each time i run this code. Is this due to the lpszPtr variable is not been delete?

regards,
Chris.C

[kedaman]

I don't see any internal memory leaks and this line:
lpszPtr = lpszPtr + 5;
seems to be redudant

[Chris]

The lpszPtr = lpszPtr just some dummy action. can be ignore
How about this?

DWORD WINAPI Functiona (LPVOID pParam)
{
   char *lpszMesage=NULL;
   char *lpszTmp=NULL;
   char *lpszPtr=NULL;
    
   TCHAR *lpszData = (TCHAR*)pParam;
   lpszMessage = new char[14];
   strcpy(lpszMessage, lpszData); 
   lpszPtr = lpszMessage
   lpszPtr++;   
   MessageBox(hWnd, lpszPtr, "Data #1", MB_OK);
   lpszTmp = new char[10];
   strcpy(lpszTmp, "123456789");
   lpszPtr = lpszPtr + 5;       
   lpszPtr = lpszTmp;
   MessageBox(hWnd, lpszPtr, "Data #2", MB_OK);
   delete [] lpszTmp;
   delete [] lpszMessage;
   
   ExitThread(WM_QUIT);
} 

[kedaman]

ah, remove exitthread, better let it terminate manually, reason why you a have memory leak

[Chris]

Just wanna to know why the ExitThread will cause memory leak?
Is that the function to terminate a thread?

What the different between terminate a thread with return 0 and ExitThread(WM_QUIT)?

Thx in advance

[CornedBee]

a) WM_QUIT is not 0. The return code of the thread will therefore not be 0.

b) ExitThread IMMEDIATLY exits the thread. It doesn't allow the CRT to clean up it's resources (assuming you used _beginthreadex to start the thread, which you should do if you use CRT functions in the thread), no object destructors to be called and no memory that was reserved to be freed (although if you forget to free anything it's lost until app termination anyway, but windows may use resources too).

Just out of interest, how did you detect the leak?

[Chris]

em... I use the CreateThread API to create a thread as below:

   TCHAR    *lpszMessage=NULL;
   HANDLE  hThread=NULL;
   DWORD  dwTID=0;
    
   lpszMessage = new TCHAR[20];
   memset(lpszMessage, TEXT('\0'), 20);
   strcpy(lpszMessage, TEXT("123456789A123456789B"));
   hThread = CreateThread(NULL, 0, Functiona, lpszMessage, 0, &dwTID);
   Sleep(50);
   CloseHandle(hThread);
   delete [] lpszMessage; 

I check the memory status on the task manager or (system on WinCE) after everytimes I execute the thread. Most of the time will be under WindowsCE environment, but it should be the same as normal window NT platform.

ea... is the CRT mean Critical Section?

So, CornedBee & kedaman both of you are recomend to use return 0; instead of ExitThread to terminate a thread it self?

[kedaman]

taskmanager only shows memory usage in kb for me, i'm using win2k, i guess you can use the performance counters, i checked them out quite a while ago...
yeah return to halt the thread and you'll be fine.

[CornedBee]

CRT is the C runtime library (like strcpy, malloc...). Especially the functions strtok and asctime are extremely endangered whenever used in a thread without _beginthreadex (use process.h).

   hThread = CreateThread(NULL, 0, Functiona, lpszMessage, 0, &dwTID);
   Sleep(50);
   CloseHandle(hThread);
   delete [] lpszMessage;

That piece of code is extremely dangerous. Although it is highly likely, you can't guarantee that the created thread will get a chance to execute any code before Sleep returns. This way, lpszMessage would be deleted before the thread accesses it. When it then does, it will cause an access violation.

It would be better if the thread frees the memory itself just before finishing. Or let the primary thread wait for the other thread's end with WaitForSingleObject. Rather a bad idea cause you can't continue with code during this time which makes multithreading rather senseless.