Memory Leak Detecting and overriding new?

Question

I am attempting to get Memory leak detection working with the help of these two articles: http://msdn.microsoft.com/en-us/library/e5ewb1h3%28VS.80%29.aspx http://support.microsoft.com/kb/q140858/

So in my stdafx.h I now have:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#define new new(_NORMAL_BLOCK,__FILE__,__LINE__)

The only problem is, I have a class which overrides the new function:

class Dummy
{    
  //overloaded new operator
  void FAR* operator new(size_t cb);
}

Now when I compile this code, I get: error C2059: syntax error : 'constant' error C2091: function returns function

Any idea how I can fix this?

Answer 1

You can use pragma directives to save and restore the new macro when undefing for overloads. See [MSDN](http://msdn.microsoft.com/en-us/library/hsttss76(VS.71).aspx) for the exact syntax.

E.g.

#pragma push_macro("new")
#undef new
void FAR* operator new(size_t cb);
#pragma pop_macro("new") 

You can put these in headers, e.g.

begin_new_override.h:

#ifdef new
#define NEW_WAS_DEFINED
#pragma push_macro("new")
#undef new
#endif

end_new_override.h:

#ifdef NEW_WAS_DEFINED
#undef NEW_WAS_DEFINED
#pragma pop_macro("new")
#endif

And then

#include "begin_new_override.h"
void FAR* operator new(size_t cb);
#include "end_new_override.h"

Answer 2

Redefining new via #define at the preprocessor level is a bad idea in my experience -- you not only break operator new overloads, but also placement new, and probably a few other things.

Having all those FILE and LINE macros expanding everywhere causes your .rodata and .data sections to bloat with file strings and line numbers, and generates much more code per call.

Much better (if more effort up-front) to take advantage of the existence of debug information (e.g. .pdb file) and use something like the DbgHelp library's StackWalk64 to gather stack info.

Overload the various combinations of global operator new and operator delete (array, nothrow, etc), have them store and release stack information as memory is allocated and freed.

You can even store this information in a structure like a std::map<void *, StackInfo>, just be careful to not record the allocs caused by the map inserts (a global lock may be sufficient for a single-threaded app, multi-threaded is left as an exercise to the reader).

Since you're recording the entire stack for any given alloc, you can do some nifty tree analysis, grouping allocations (leaks or otherwise) by "function and descendants"... And it is sometimes easier to trace complicated leaks if you know the entire stack from their allocation time.