Make process crash on large memory allocation

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 runn开发者_如何学编程ing 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 ?

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.

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.

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.

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.

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

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.