Make process crash on large memory allocation

Question

I'm trying to find a significant memory leak (15MB at a time, but doing allocations like this on multiple places). I checked the most obvious places, and then used AQTime, but I still can't pinpoint it. Now I see 2 options left:

1) Use SetProcessWorkingSetSize: I've tried this but my process happily keeps on running when using up more then 150MB:

DWORD MemorySize = 150*1024*1024;
SetProcessWorkingSetSize( GetCurrentProcess(), MemorySize/2, MemorySize*2 );

2) Put a breakpoint when allocating more then 1MB at a time. How should I do this, overload operator new with an 'if>1MB' inside ?

Answer 1

SetProcessWorkingSetSize doesn't mean what you think it means - it's a clue to the OS on how much memory to keep "in memory" versus paged to disk. Modern OSes are very aggressive when it comes to paging unused memory to disk - Windows particularly so.

IBM Rational Purify is your only solution other than a very thorough code analysis. On Windows, for C/C++, there is no better tool for finding memory leaks. On Mac or Linux you could use valgrind, but AFAIK, it's not yet working on Windows.

Answer 2

1) Use SetProcessWorkingSetSize: I've tried this but my process happily keeps on running when using up more then 150MB:

What is SetProcessWorkingSetSize returning? Is the call succeeding?

2) Put a breakpoint when allocating more then 1MB at a time. How should I do this, overload operator new with an 'if>1MB' inside ?
Yes, that should work.

It might be helpeful to examine the tools provided by the C Runtime Debug Heap provided by MSVC.

Answer 3

On an embedded type system, we would do exactly as you suggest - putting a break on any call to new/memAlloc above a certain threshold and do the same on free/delete. Tedious, but it will ge the job done. A condtional breakpoint on the size should do what you want, but on the delete, it's a bit worse.

Answer 4

Try to use UMDH. It is a free Microsoft utility that allows to find memory leaks.

Answer 5

From your tags you are using c++ and visual studio.

In that case you can simply use the crt debug hooks that Microssoft provide for you.

Search msdn for _CrtSetAllocHook.

In a debug build this will allow you to intercept every allocation - you can ignore small ones and just set a break point or call ::DebugBreak on the large ones.

Answer 6

Sorry all, none of the proposed solutions worked. It finally got fixed using AQTime and a lot of debugoutput. The leak got cleaned on shutdown, so it was looking for a needle in a haystack.

Still I'm interested in how to efficiently find this though. I tried to put a conditional breakpoint on the new operator, but the debugger took ages to evaluate "bytes > 1024 * 1024" for every single allocation.