• 13
• 18
• 19
• 27
• 10

# tracking memory leaks

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

## Recommended Posts

Hello. Up till now iv been using _CrtMemState to track memory leaks, one at the beginning of main() and one at the end. This approach feels pretty limited, i generaly check the output once in a while and if it has pickedup a leak i sit and comment large portions of code out until i can pin-point the leak. What im wondering is if anyone is familiar with a better way, iv heard there are 3rd party external apps that you can hookup to the process or debugger to track memory. Are there any free/good ones? I know there is also the possibility to overload new&delete and build your own custom memory tracker but i would rather not have to do that if possible. Or maybe there is some other, better way? Thanks in advance.

##### Share on other sites
I don't know of any free external application, but I suggest taking a look at this. It is a free memory manager by Paul Nettle that you can integrate to existing applications quite easily.

##### Share on other sites
 Aldenar's typing skills > mine [embarrass][/edit]
What I would do is use a custom memory leak tracking library. I am trying out Paul Nettle's, I have heard good things about it. It was here on flip code but the link no longer works. I did a google search and was unable to find any links that worked, so I have uploaded it to my web page. To use it, all you have to do is:

#include "mmgr.h"

then at the end of your program:

m_dumpMemoryReport();

I would *strongly* suggest reading the source code files b/c they explain some important stuff. I hope this helps!

##### Share on other sites
Official link here Fluid Studios MMGR. Apparently Fluid Studios took Nettle's code and updated(?) it?

It integrates VERY nicely in my own engine, and it has even detected memory leaks in some libraries I use- I recompiled the libraries with the MMGR to pinpoint the leak (on VC7 it tells you file, function, and line) and then fixed them. Read the docs in the source. Make sure #include "mmgr.h" is the very last include in each source file, and don't include it in the headers: STL doesn't like being memory managed :) This is contrary to the docs, but after butting my head against the official instructions I realized that this accomplishes the same thing without any hassle.

MMGR dumps a file telling you your leaks at the end of execution, as well as a file logging each allocation and deallocation if STRESS_TEST is enabled. These files are complete with file, function, and line, of course. It is probably easiest to include it in your project, but you can compile it as a library if you don't need to edit the flags regularly.

Quote:
 then at the end of your program:m_dumpMemoryReport();

Not in this version, at least... all you do is include mmgr.h and it logs leaks automagically

##### Share on other sites
I think Nettle founded or works for them, the last time I emailed him he said something about that, but its been some time now. Thank you for the link though! I couldnt find it anywhere.

##### Share on other sites
Yup, fluid studios was founded by Paul Nettle way back in 1999, according to http://www.fluidstudios.com

##### Share on other sites
Thanks guys, i will try it out :-)

##### Share on other sites
For anyone using the CRT tools (I've had to use them when MMGR does not co-operatre with some library):

When you get a leak (or other heap error), you'll get some number in squiggly brakcets like {2342}. First run your program a few times more to check it's the same number every time. What you do is take that number, and at the top of your main function, drop in:

_CrtHaltOnAloc(2342);

Which will then assert just before that particular peice of memory is alocated. That will tell you what object is being leaked, and will help you a great deal in fixing it.

Note: That function name is from memory - it could be something similar.

MMGR is much better, it's unfortunatly less compatable than the CRT stuff, though.

##### Share on other sites
Not that I want to hijack a thread, but I use the MMGR header/code... absolutely genius bit of work. However, I get a random number of leaks reported each time I run the program - often only 5 or 6. None of them can be identified in the log (the source is ????::????)

However, MMGR is configured fine for every translation unit and has picked up every other leak (my program was a bit of a sieve before I used it!). Anyone ever seen it do this?

I keep wondering if it's picking up something that initialized externally and managed by something else (e.g. the STL), but I haven't managed to find a good answer yet.

cheers,
Jack

##### Share on other sites
 ----------------------------------------------------------------------------------------------------------------------------------|                                          Memory leak report for:  12/16/2004 12:10:42                                            | ---------------------------------------------------------------------------------------------------------------------------------- 28 memory leaks found:Alloc.   Addr       Size       Addr       Size                        BreakOn BreakOnNumber Reported   Reported    Actual     Actual     Unused    Method  Dealloc Realloc Allocated by------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- --------------------------------------------------- 000196 0x089303F0 0x0000001C 0x0892F3F0 0x0000201C 0x00000000 new         N       N    cubedemo.cpp(00186)::CubeDemo::init000093 0x089406E0 0x00000028 0x0893F6E0 0x00002028 0x00000000 new         N       N    ??(00000)::??...

The discrepancy between the reported size and actual size comes from MMGR adding an extra 0x2000 bits (1024 byte)of memory to each allocation for testing: you can change this behavior with a flag in mmgr.cpp.

You get the unknown location of the leak when the file the leak is in is not including "mmgr.h" - ie, in an external library you are linking with. If you can deduce what library the leak is in, recompile it with "mmgr.h" included in all source files and relink your app. It will now use the #defines in mmgr.h to pinpoint the leak.

I haven't had any trouble with the STL leaking in the past... at the moment, as my log shows, I have 28 leaks in some library or another (I just went on a functionality spree and added about 6 libraries, debugging this will be fun). I guess it is technically possible that it's STL, but it is impossible to debug it (STL barfs if you try to memory manage it - try including "mmgr.h" before any of your STL includes and you shall see).