DaniWeb Forum Index > Software Development > C++

C++ RSS

Visual Studio Memory Dump

Please support our C++ advertiser: Intel Parallel Studio Home

•

Join Date: Dec 2008

Posts: 24

Reputation: GadiK is an unknown quantity at this point

Solved Threads: 0

GadiK

Offline

Newbie Poster

Visual Studio Memory Dump

Mar 1st, 2009

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.

 Help with Code Tags 
 CPP Syntax (Toggle Plain Text) 
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;
}
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)

•

Join Date: Aug 2005

Posts: 15,494

Reputation: Ancient Dragon has a reputation beyond repute

Solved Threads: 1478

Ancient Dragon Ancient Dragon is offline

Offline

Still Learning

Re: Visual Studio Memory Dump

Mar 1st, 2009

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.

Don't PM me with questions -- you might get a nasty PM in response. If you have a question then post it in one of the forums.

•

Join Date: Dec 2005

Posts: 5,850

Reputation: Salem has a reputation beyond repute

Solved Threads: 749

Salem

Offline

Void main'ers are DOOMed

Re: Visual Studio Memory Dump

Mar 1st, 2009

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

Help with Code Tags

(Toggle Plain Text)

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.