Archived

This topic is now archived and is closed to further replies.

how to detect memory leaks?

This topic is 5179 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

Well, not "after" your program runs. After your program completes, all of its resources are automatically freed by the OS. But by instrumenting your program with leak detection, you can see which resources aren''t being freed manually.

What compiler/architecture are you using?


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
MSVC++ with DirectX. I''m using a std::list to create a texture manager to hold all my textures.

I put a logging system, put it only says "Freeing texture..." etc etc. But I''m using lists and I think I botched my code up (:-(). So...I woud like to know how many bytes of unfreed memory I have (if any).

Share this post


Link to post
Share on other sites
Read this. Also note that memory leak checkers won''t tell you about unfreed DX resources. For that, use the debug DX runtime and check the debugging output.


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
You can put this code in the top of your WinMain function to see if there are any leaks:

//include crtdbg.h for this to work
int flag=_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
flag|=_CRTDBG_LEAK_CHECK_DF;
_CrtSetDbgFlag(flag);

When debugging your program in MSVC++, after you exit there will be a readout in your debug window telling how much memory was leaked, if any. It doesn't really help you find where the memory is being lost, but at least it tells you that it is.






"Skepticism.... that great rot of the intellect." - V.H.
Bah, what does HE know?


Albekerky Software


[edited by - sliderag on October 13, 2003 8:10:42 PM]

Share this post


Link to post
Share on other sites
If you''re running on win32 (particularly vc, although I expect it will work in other dev environments) there is a program called boundschecker which can be integrated into your program for debugging purposes. It can track your apps memory and will report any anomalies at shutdown.

A possible home brew solution is to overload the new and delete operators and track allocations and de-allocations your self. I believe there is an article in one of the GPG books (I think the second one) that details how to do this. Won''t go into details, rather not confuse you as its been a while since I read it. I expect searching the forums or google on memory managers might yield results.

Share this post


Link to post
Share on other sites
If you use C++ style allocations(new and delete), you could use my home made memory tracer. It overloads the new/delete operators and stores everything in a std::list. Before killing your application, you just call DumpMemoryLeaks("memory-dump.txt"); to see what mem leaks occured. Output is in this form:


X:\Projects\YourProject\main.cpp(25): 0xbaadf00d(80 bytes)


You can find the memory tracer at http://http://home.wanadoo.nl/vdwillik/code/MemTracer.h

Toolmaker



-Earth is 98% full. Please delete anybody you can.

Share this post


Link to post
Share on other sites
I''m sure Toolmaker''s solution will probably work fine, but I might as well tell you what I''ve used: MMGR. You''ll find a link to it at the bottom on that page. It''s saved me a lot of trouble in finding leaks

Share this post


Link to post
Share on other sites
Sneftel's solution is the best. In particular he was the only one who mentioned that you can't track DirectX 8 resource usage using conventional memory leak tracers, so don't even bother.

If you want good leak tracing for non-DirectX stuff, then use the CRT functions like he mentioned. Don't bother using a homemade memory manager. Not only is it likely to be less efficient than the CRT functions, but they all suffer from the problem that they don't take destructors into account at the end of a program.

If I remember right, this is the order of what happens when a program ends... You can verify this by stepping into the assembly code right at the very end of your program to see what is really going on:
1. atexit() is called
2. all destructors are invoked
3. if the CRT leak trace flag has been set, then a leak dump is made to the debug window
4. the process is terminated

So as you can see, Win32 programs already basically have memory leak tracing built in which takes the destructors into account, all you have to do is a little bit of setting up to make your application actually use it.

Here's a quick bit of sample code which you can use:

----File: memory.h------

#pragma once

#include <windows.h>

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define DEBUG_NEW new( _NORMAL_BLOCK, THIS_FILE, __LINE__ )
#endif

void EnableLeakDetection( void );

----File: memory.cpp-----

#include "Memory.h"

void EnableLeakDetection( void )
{
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
}


----File: YourCode.cpp-----

#include "Header1.h"
#include "Header2.h"
#include "WhateverElse.h"

//////// BEGIN MEMORY CRAP //////
#include "Memory.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
//////// END MEMORY CRAP ///////

..... bunch of code, blah blah ........
char *p = new char[1000]; // A memory leak!
..... bunch of code, blah blah

That's all you need to do. Just make sure to call "EnableLeakDetection()" somewhere before the program ends, and also make sure to begin all your .cpp files like YourCode.cpp. In particular:

-Insert the section marked with "BEGIN MEMORY CRAP" into each and every single cpp file of your project, but *NEVER* into a header file.

-Put this block at the top part of your file, but *AFTER* any #includes.

-Don't do this if there's any code in the cpp file which makes use of custom new and delete operators... Some people like to define custom new and delete operators for individual classes (often to implement object pooling). You might have issues if you try to do something "crazy" like that.

Hope that makes sense!

Raj

[edited by - Rajansky on October 13, 2003 10:51:05 PM]

Share this post


Link to post
Share on other sites