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.