memory leaks for entire process lifetime

[Dave Calkins]

I've been reading Advanced Windows Debugging (excellent book!) and it
mentions a couple tools in the beginning for leak detection. Problem is,
those tools seem to all be setup around you picking a running process, taking
a snapshot, doing some stuff, taking another snapshot, and comparing.

In my case I want to track all allocations during the app's lifetime, then
when the app exits, look at anything it hasn't freed.

This doesn't seem feasible with these tools, because you have to attach to
an already running process.

Any ideas? The code I'm debugging is a native Win32 C++ MFC app and I am
using DEBUG_NEW, problem is that only gives you a line number not a call
stack and some of the tools mentioned in the book sound like they have nicer
output.

[Ivan Brugiolo [MSFT]]

Which OS are you experiencing this in ?
If you are in Vista, WS08[-R2], Win7, then, the stack capture
infrastructure for heap-allocations has changed.
It is not always a fixed region in the process address space, but, it is
dynamic.
This is an excerpt of one of my extension to dump that structure

0:000> !ivanbrugexts.heapstacktrace
ntdll!_HEAP_STACK_TRACE_LOG 0000000000060070
ntdll!_RTL_MEMORY_BLOCK_LOOKASIDE 0000000000050040
ntdll!_RTL_MEMORY_ZONE 0000000000060000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 00000000026f0000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 00000000026e0000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010b40000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000002270000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010b30000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010b20000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010b10000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010b00000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010af0000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010a30000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010a20000 00010000
ntdll!_RTL_MEMORY_ZONE_SEGMENT 0000000010a10000 00010000

You should be able to discern that with something like
0:000> !address -f:VAR,MEM_COMMIT,MEM_PRIVATE,PAGE_READWRITE
then looking for 0x10000-sized allocations with a header that looks like
list-linked.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Dave Calkins" <DaveC...@discussions.microsoft.com> wrote in message
news:D47A0892-65F9-459E...@microsoft.com...

[Ivan Brugiolo [MSFT]]

Please disregard the post. I posted the message to the wrong thread.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message
news:#RQguY2d...@TK2MSFTNGP04.phx.gbl...

[Ivan Brugiolo [MSFT]]

> In my case I want to track all allocations during the app's lifetime, then
> when the app exits, look at anything it hasn't freed.

This is a common request for folks coming from the constrained Visual-Studio
C-Runtime Debug-Heap world.
In that world, it is somewhat possible to add a function late enough
in the component lifetime (end of main, DllMain(PROCESS_DETACH))
where you can get meaningful results.
In real world scenarios, there are complex components that keeps
process-wide caches, or process-wide structures (comes to mind
the ole32-class registration) that gets torn down very late, if they ever
are.
For this reason, at the OS level, it would be extremely challenging to
distinguish by-design process-termination leaks, legitimate leaks
and everything in between. Also, while you can somewhat constrain
your application to use everything from the C-Runtime heap,
and control over that, you cannot do that for OS components
that have to use special heaps or private heaps.

>> This doesn't seem feasible with these tools, because you have to attach
>> to
>> an already running process.

This is not needed. You can start your application from the debugger,
and inspect the heap applications of the C-Runtime heap when,
for example, WinMain exits.

>> Any ideas? The code I'm debugging is a native Win32 C++ MFC app and I am
>> using DEBUG_NEW, problem is that only gives you a line number not a call
>> stack and some of the tools mentioned in the book sound like they have
>> nicer output.

The Debug-Heap of the C-Runtime is notorious for defeating the stack
capture mechanism of the OS (for x86 at least) because of frame pointer
optimizations.
Use the non-debug version, or, make sure the operator new implementation
does not have FPO.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Dave Calkins" <DaveC...@discussions.microsoft.com> wrote in message
news:D47A0892-65F9-459E...@microsoft.com...

[Jochen Kalmbach [MVP]]

Hi Dave!

> Any ideas? The code I'm debugging is a native Win32 C++ MFC app and I am
> using DEBUG_NEW, problem is that only gives you a line number not a call
> stack and some of the tools mentioned in the book sound like they have nicer
> output.

You could simply use my "LeakFinder":
It will give you exactly what you want ;)
The complete stack-trace at program exit.

http://www.codeproject.com/KB/applications/leakfinder.aspx
The latest version can be found here:
blog.kalmbachnet.de/files/LeakFinder_RC9.zip

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/