Jump to content
  • Advertisement
Sign in to follow this  

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Sfpiano
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.

*** 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!