UMDH seems to miss allocations

[J Avery]

UMDH appears to not give a complete log of all the heap
allocations of my program. UMDH generates ~3.7 MBytes of
logging, and the stack traces in the log look reasonable.

From the description in
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q268343
, I would expect the log to include every heap allocation.
However, I did not see an allocation that I knew to leak,
even after using a debugger to step a few lines past the
allocation and then running UMDH.

Does something simply run out of space and I need to
increase some parameter? For instance, I wondered about
this comment at the beginning the UMDH log: "Database size
00200000".

I build with VC++ 6.0 and have tried both Windows 2000 SP2
and SP3. I have tried both the old UMDH that Q268343 used
to point to and the new UMDH that came with the Debugging
tools for Windows (dbg_x86_6.0.17.0.exe).

Using "umdh -t:0" to explicitly give a threshold of 0 (the
default according to the documentation) did not make any
difference.

Thanks, J Avery

[Pavel Lebedinsky]

Do you mean that UMDH doesn't show the stack trace
for the leak, or that it doesn't show the address of the
leaked block when using -d option ("Dump address
of each outstanding allocation")?

If it doesn't show the stack trace, it's probably because
of the FPO issues. If you allocate memory through CRT
or OLE functions, the stack traces are usually incomplete
because these functions are FPO optimized.

[J Avery]

I found no stack trace at all for the leaking allocation.
I did see stack traces of other routines in the same DLL
that called new and had basically the same caller, and
those stack traces looked complete and correct. I had
compiled this DLL DEBUG, without optimization, though I
used a RELEASE version of the main exectutable and some
other DLLs.

Would routines compiled without optimization have FPO
issues? Would UMDH omit entirely a stacktrace that had a
Frame Pointer Omission?

Thanks, J Avery

>.
>

[Pavel Lebedinsky]

"J Avery" wrote:

> Would routines compiled without optimization have FPO
> issues?

No. But most likely the problem is not with your functions.
It's internal CRT and OLE alloction routines that are FPO
optimized.

> Would UMDH omit entirely a stacktrace that had a
> Frame Pointer Omission?

Usually the stack trace will be incomplete. This is typical
example:

00008470 bytes in 0x43 allocations (@ 0x00000028 + 0x000079F8) by:
BackTrace00124
ntdll!RtlDebugAllocateHeap+0x000000FD
ntdll!RtlAllocateHeapSlowly+0x0000005A
ntdll!RtlAllocateHeap+0x000008C2

You could try running UMDH on a full debug build
so that all C++ allocations go through msvcrtd.dll
which I think is not FPO optimized.

You might also get better results on a checked NT build.

[J Avery]

I believe I confirmed with the debugger that the allocation
I expected to see had gone through the msvcrtd.dll. UMDH
does show comparable new's from my application's DLL
invoking the MSVCRTD!operator new.

>.
>

[Ivan Brugiolo [MS]]

as far as I remember, msvcrtD.dll (the debug version) does not use the heap
implementation
provided in NTDLL.DLL, so PageHeap cannot help there.

To "help" the function that captures the stack backtrace to deal with
optimized code,
you can try to "decorate" your functions with the alloca-trick

HRESULT Foo()
{
DWORD * pDW = (DWORD *)_alloca(sizeof(DWORD));
Class * p = new Class();
return S_OK;
}

this usually helps a lot in having good stack traces.

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

"J Avery" <jkav...@yahoo.com> wrote in message
news:a6cf01c25065$726fe550$3aef2ecf@TKMSFTNGXA09...

[J Avery]

Sorry Ivan, I didn't follow your explanation. I compiled
the routines in question debug, without optimization. Did
you mean to say that umdh might fail to notice new's made
by such routines? Should I only compile release without
optimization to get good umdh output?

>.
>

[Ivan Brugiolo [MS]]

I was trying to give 2 suggestions:
-1- never use an allocator that is not provided by NTDLL if you want to use
PageHeap.
-2- when using PageHeap, in order to get better stack backtraces, use the
_alloca() trick, even in optimized retail code.
(in many cases it helps getting better traces,
but still certain optimization still can fool the routine that
captures the backtraces)

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

"J Avery" <jkav...@yahoo.com> wrote in message

news:c8da01c25352$b6a55f30$a4e62ecf@tkmsftngxa06...