Visual Studio Memory Dump

[GadiK]

Hi Guys.
I wrote a nice MFC application.
This app uses a number of threads and is meant to manage rs232 communication with a microcontroller.
When I send or receive data Visual Studio informs me of a Memory Leak:
Detected memory leaks!
Dumping objects ->
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {184} client block at 0x0036AFC0, subtype c0, 68 bytes long.
a CWinThread object at $0036AFC0, 68 bytes long
{153} normal block at 0x00368C00, 5 bytes long.
Data: <DONE > 44 4F 4E 45 00
{152} normal block at 0x00368BC0, 1 bytes long.
Data: < > 00
{151} normal block at 0x00368B78, 5 bytes long.
Data: <DONE > 44 4F 4E 45 00
{150} normal block at 0x00368B38, 1 bytes long.
Data: < > 00
{64} client block at 0x00363398, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $00363398, 64 bytes long
Object dump complete.

Even before I perform any sending or receiving I get a memory leak:
Detected memory leaks!
Dumping objects ->
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {184} client block at 0x0036AFC0, subtype c0, 68 bytes long.
a CWinThread object at $0036AFC0, 68 bytes long
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {157} normal block at 0x00368DE8, 49 bytes long.
Data: < >x > EC 97 3E 78 14 00 00 00 20 00 00 00 01 00 00 00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(195) : {156} normal block at 0x00368D50, 88 bytes long.
Data: < > E8 03 00 00 00 00 00 00 E9 03 00 00 00 00 00 00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(181) : {155} normal block at 0x00368CE0, 48 bytes long.
Data: < > FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
{153} normal block at 0x00368C00, 5 bytes long.
Data: <DONE > 44 4F 4E 45 00
{152} normal block at 0x00368BC0, 1 bytes long.
Data: < > 00
{151} normal block at 0x00368B78, 5 bytes long.
Data: <DONE > 44 4F 4E 45 00
{150} normal block at 0x00368B38, 1 bytes long.
Data: < > 00
{64} client block at 0x00363398, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $00363398, 64 bytes long
Object dump complete.

I included the _CrtDumpMemoryLeaks() func in my Receiving Thread.

What Does this mean??
When I try to send a large file, Visual Studio is showing me
DATA: <SENDING> messages with a bunch of other data.
Although the data does go through without any problem, the memory dumping prevents me from closing my application and the memory usage is of the roof.

Here's my sending fucntion.

BOOL Cterminal_projDlg::TX_Func(LPVOID pPARAM)
{
	OVERLAPPED osWrite = {0};
	DWORD dwWritten;
	BOOL fRes;

	Cterminal_projDlg *pSender = (Cterminal_projDlg *) pPARAM;

	// Create this writes OVERLAPPED structure hEvent.
	osWrite.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
	if (osWrite.hEvent == NULL)
	{
	  AfxMessageBox("Error creating overlapped event handle");
	  return FALSE;
	}

	// Issue write.
	if (!WriteFile(pSender->ComConfig.Serial.m_hComm, pSender->lpBuf, pSender->dwToWrite, &dwWritten, &osWrite)) 
	{
		  if (GetLastError() != ERROR_IO_PENDING) 
		  { 
			 AfxMessageBox("WriteFile failed, but it isn't delayed. Report error and abort");
			 fRes = FALSE;
		  }
		  else 
		  {
			// Write is pending.
			if (!GetOverlappedResult(pSender->ComConfig.Serial.m_hComm, &osWrite, &dwWritten, TRUE))
			{
				AfxMessageBox("Write Failed");
				fRes = FALSE;
			}
			else
			// Write operation completed successfully.
				fRes = TRUE;
		  }
	}
	else
	// WriteFile completed immediately.
	fRes = TRUE;

	CloseHandle(osWrite.hEvent);
	_CrtDumpMemoryLeaks();
	return fRes;
}

How do I find where the problem is? (It's not necessarily in this thread)

[Ancient Dragon]

1) try commenting out large sections of code until no more leaks detected.

2) Sometimes it reports leaks that are not really leaks. such as memory allocated by MFC classes or your own code and not yet released when CrtDumpMemoryLeaks() is called.

[Salem]

http://msdn.microsoft.com/en-us/library/faz3a37z.aspx
Read this, and find out how to build your program with debug malloc enabled.

At the start of main, put a breakpoint on your first call to malloc. It's only necessary because I can't remember the name of something :(

When you hit the breakpoint, do step-into malloc, and follow where it goes.
Shortly, you'll come across something which looks like this

if ( ++allocnum == count ) {
  breakIntoDebugger();
}

The name of count is very useful, write it down, and you can forget all of this step.
Put the counter into a watch window for easy reference (and subsequent changing).

Now for the real magic.

{151} normal block at 0x00368B78, 5 bytes long.
Data: <DONE > 44 4F 4E 45 00
The numbers in braces ARE the allocation numbers. If you (in this example) put 151 into the counter you've identified, then the debugger will break when you're about to allocate a block which is going to leak.
You can then track back into your code to see exactly what it's used for, and from then figure out why you're not freeing it.

Put the count value into the count variable, hit "go" and wait for the breakpoint.

Start with the lowest numbered allocations first.