Memory leaks in release version, not debug

This topic is 4759 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I use fluid studio's memory manager to track my leaks, and when I run my program in debug mode, it says it can't find any leaks. However if I run it in release mode, I get around 100 memory leaks per second. Any ideas as to what could be causing this?

Share on other sites
Best thing for you to do is look at the log and see where the leaks are happening and check that code. There could be many things that could be going on in your code [sad] Just try and isolate the area and then work from there, perhaps post that code once you are sure that's what's causing the problem.

Share on other sites
The problem with that is that the memory manager output is like this:
new N N ??(00000)::??

for all X amount of leaks.

Share on other sites
Eeek, that's not good. Have you made sure to include the 'mmgr.h' file in your .CPP files to make sure it can generate the information? If that doesn't help, then you will need to search for all 'new' statements and try and take a look at yourself. About how many 'new's are you calling? Also if I may ask, what type of project is it? Finally, keep in mind that if you use global variables, MMGR cannot track those correctly, simply because they will be deallocated after MMGR is shut down. Just a few tips.

Share on other sites
Ok, i found the function, but I don't see where it's being leaked; I assumme it's based on my lack of knowledge about MFC.

#define SAFE_DELETE(p)       { if(p) { delete (p);     (p)=NULL; } }...void CMyApp::Update() {	CDC* pdc = new CDC;	SAFE_DELETE( pdc );}BOOL CMyApp::OnIdle(LONG lCount) {	Update();	return CWinApp::OnIdle( lCount );}int CZigguratApp::Run() {	ASSERT_VALID(this);	_AFX_THREAD_STATE* pState = AfxGetThreadState();	// for tracking the idle time state	BOOL bIdle = TRUE;	LONG lIdleCount = 0;	// acquire and dispatch messages until a WM_QUIT message is received.	for (;;)	{		// phase1: check to see if we can do idle work		while (bIdle &&			!::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))		{			// call OnIdle while in bIdle state			if (!OnIdle(lIdleCount++))				bIdle = FALSE; // assume "no idle" state		}		// phase2: pump messages while available		do		{			// pump message, but quit on WM_QUIT			if (!PumpMessage())				return ExitInstance();			// reset "no idle" state after pumping "normal" message			if (IsIdleMessage(&(pState->m_msgCur)))			{				bIdle = TRUE;				lIdleCount = 0;			}		} while (::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE));		/////////////////////////////////////////////////				Update(); ///<---	}	ASSERT(FALSE);  // not reachable}

Update() gets called during my app's OnIdle function and during the app's run function.

[Edited by - Sfpiano on May 10, 2005 8:43:12 PM]

Share on other sites
Quote:
 Original post by SfpianoOk, i found the function, but I don't see where it's being leaked; I assumme it's based on my lack of knowledge about MFC.*** Source Snippet Removed ***Update() gets called during my app's OnIdle function and during the app's run function.

Ok, here's the deal.

Every time you use Update you are creating a pointer to a new area in memory. That is, when you update, you aren't deleting the old stuff that's previously been saved, but you get pointed to your new CDC value. At least, that's what it looks like to me, I have no idea what happens to the flow of control when you call SAFE_DELETE. I'd have to see what SAFE_DELETE does, but evidently there isn't any 'delete' function called for the previously allocated memory for your CDC values. This whole structure is within a for(;;) loop, so you'll be burning through memory fast.

Hope this helps.

Share on other sites
The definition of SAFE_DELETE was at the top of the source

#define SAFE_DELETE(p)   { if(p) { delete (p);  (p)=NULL; } }

Share on other sites
I don't know how good that is to do something like that. Try something else like making these changed:
class CMyApp{private:   CDC* pdc;public:   CMyApp::CMyApp();   CMyApp::~CMyApp();};CMyApp::CMyApp(){   pdc = new CDC;}CMyApp::~CMyApp(){   SAFE_DELETE( pdc );}void CMyApp::Update() {	}void CMyApp::Update() {// use pdc here}

Not sure all what you are doing, but at least see if that takes care of all the memory leaks. Here's the MSDN page for CDC.

Share on other sites
It's just a macro for deleting objects. It's the equilivent of:

delete pdc;
pdc = 0;

Share on other sites
Are you maybe mixing debug and release (debug dll, but release program)?

I had fugly memory leaks when i had to use a external debug dll (they didn't ship a release dll at all) and i compiled my program in release mode. It worked clean and fine in XP, but on NT and 2000 you'd have massive leaks. It looked like the memory manager of Windows didn't like the mixing of both and every call to delete did nothing at all (it did in XP though).
Took quite a while to figure out, actually it was just a random guess.

If it's not that, you might try to replace the "new" with a real CDC instance to remove the dynamic memory.
Other things i could think of: What are you doing with the CDC? Maybe you aren't releasing or unselecting some Windows resources with the DC?

• 19
• 10
• 19
• 14
• 20