UMDH appears to not give a complete log of all the heap

ufwt

unread,

Feb 13, 2003, 8:58:41 PM2/13/03

to

UMDH appears to not give a complete log of all the heap
allocations of my program.
I Think because the size of trace database too small.
how change the size of trace database ?
I use gflags -tracedb,but can not work.

please help!
thanks.

Pat

unread,

Feb 13, 2003, 10:42:16 PM2/13/03

to

UMDH will only capture allocations to the heap manager provided by NTDLL.
If you leverage other heap managers or call other memory allocators (e.g.
VirtualAlloc(), any COM allocator, etc.), UMDH will miss them.

That said, have you verified that you have good symbols for NTDLL, MSVCRT,
and your dll? If not, then it is unlikely that you will get good stacks.
Also, the memory allocation tracing does a 'best effort' matching up
allocations from various partial stacks. Sometimes, if the API can't
identify the stack that allocated the memory, the allocation will be stuck
in a default allocation stack. Usually, that stack terminates in the
MSVCRT!<some memory function>, with no caller below that. They are also
identified by an unusually large number of allocations assigned to it.

Pat

"ufwt" <ling....@mail.zte.com.cn> wrote in message
news:7b27f93b.0302...@posting.google.com...

ufwt

unread,

Feb 14, 2003, 1:42:15 AM2/14/03

to

I have good symbols for NTDLL, MSVCRT.
I only use call malloc n(n>10000) number
such as :
void f(int i){
if(i == 0) return;
i--;
malloc(9);
f(i);
}
when i is large,then umdh can not catch alloc.

"Pat" <patf...@online.microsoft.com> wrote in message news:<sAZ2a.92108$SD6.5333@sccrnsc03>...

Pat

unread,

Feb 14, 2003, 2:52:08 AM2/14/03

to

Do you have the SBH (Small Block Heap) enabled? An allocation that small
would go there by default (which would not be picked up by UMDH). Also,
just for testing purposes, have you tried replacing malloc with HeapAlloc()?

Pat

"ufwt" <ling....@mail.zte.com.cn> wrote in message

news:7b27f93b.03021...@posting.google.com...

Ivan Brugiolo [MSFT]

unread,

Feb 14, 2003, 10:36:34 AM2/14/03

to

Your function looks recursive as well,
and this, together with FPO optimization ebabled,
can lead to missing / incorrect stack traces.

try something like

void Leak(int Max)
{
for (int i = 0;i<Max;i++)
{
void * p = HeapAlloc(GetProcessHeap(),0,SIZE);
}
}

or at least drop a line such as

DWORD * pDW=(DWORD *)_alloca(sizeof(DWORD)).
if your own function.

_alloca is regarded as being very beneficial to to the stack-backtrace
capture routine,
since it forces a frame even in presence of FPO optimization
(at least on IA32, For IA64 stacks are almost always correct anyway).

BTW, CoTaskMemAlloc, in recent OSes, goes to the process heap in the retail
builds.

--
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

"ufwt" <ling....@mail.zte.com.cn> wrote in message

news:7b27f93b.03021...@posting.google.com...

ufwt

unread,

Feb 16, 2003, 11:17:00 PM2/16/03

to

I real known how to change the trace database size ?
thanks.

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<#8AhO7D1CHA.2696@TK2MSFTNGP09>...

ufwt

unread,

Feb 17, 2003, 3:56:32 AM2/17/03

to

I only need to know how to change the size of trace database size!
thanks!

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<#8AhO7D1CHA.2696@TK2MSFTNGP09>...

Leon

unread,

Feb 24, 2003, 9:58:43 PM2/24/03

to

I have run the umdh for notepad.exe.

But the output is not what I expected:
//
// UMDH: version 5.2.3692.0: Logtime 2003-02-25 09:43 - Machine=ciq - PID=3040
//

// OS version 5.0 Service Pack 3
// Umdh OS version 5.2
// Debug privilege has been enabled.
// Connecting to process 3040 ...
// Process 3040 opened (handle=24) ...
// Debug options set: 00000007
// Debug library initialized ...

It didn't show any backtrace information.

Anyone know why?