Memory leaks as we all know are an annoying problem. But again I'm sort of hung up trying to think of a way to avoid them. I know how smart/intrusive pointers work and how to use them, but this feels like an incomplete solution. If I forget to use a smart pointer I could potentially leave some memory undeleted, thus causing a leak. I'm wondering what people have used as solutions to memory problems. Ideally I'd like some sort of solution that causes a very clear runtime error if a memory leak is allowed. It should allow me to see what memory I forgot to delete, etc. Currently the only solution I can think of is to allocate some big pool of memory at the beginning of my program, then force (somehow, overloaded new perhaps?) everyone to use that pool and tag the memory they allocate so that at the end of the program I can see if there are any remaining tags. The problem is that this solution seems somewhat inflexible. Is this much security even necessary? Are there other possible solutions that anyone knows of? I know this is a very broad subject and the correct solution depends highly on what type of application is being written, but I think for now I'd just like to see what solutions people have used to give me an idea of what's out there. Any ideas would be appreciated. Sam

Your compiler/runtime library may have leak tracking functionality built in. For example with MSVC you can use _CrtDumpMemoryLeaks() or _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ).

Use a separate tool instead

Wow, thanks for the fast responses. Those look like very handy tools. Are these Microsoft specific, though? I am currently using MSVC but I would also like to know some solutions that would be portable to other development environments.

Great advice, though, I will certainly try to make use of this functionality.

purify

and

valgrind

Basically, not matter what major platform you're on, something will be available.

Or, just don't create memory leaks. :)

Quote:Original post by UltimateWalrus
At the end of the program, just check the "Allocations" variable; it should be 0. If it's not, you have a memory leak (although you'll have to figure out where by yourself). ;)

That method is somewhat problematic. Consider the fact that you may have pointers that last for the entire life of the application. You do not have to bother deleting these since all memory your application claims during execution is returned to the system after termination anyways.

A memory leak involves you "losing handles" to memory during execution

ie.

int* a = new int[100];
a = (int*)5; // how the hell do we access our array now?

Now that memory is now lost for the entire execution of the application.

Using a more advanced tool will give you information about which pointers have not been free'd, not just that some stuff hasn't been free'd.

My memory manager; Overloads operators new and delete, has some stack walking functions to determine where allocations came from, is thread safe, and works with X64:
PMemory.h, PMemory.cpp.
That code won't compile straight out of the box, but it should with some minor modifications (E.g. removing my assert calls and so on). It should work with other compilers (untested), the only MSVC specific part I know of is the #pragma init_seg(compiler) call (Which is there to ensure the memory manager global is constructed before STL globals, so it can track STL "leaks").