RE: UMDH with Release Builds

[Anubhav]

Sorry, I am so tired that I am missing to put all information in one go.

I have also ensure that the symbol _NT_SYMBOL_PATH contains the path to my
application PDBs (which is why I think UMDH works perfectly with my debug
build)

"Anubhav" wrote:

> Forgot to mention:
>
> I am using the latest version of Debugging tools for Windows and this
> problem happens when I build with either VC++6.0 or with VS 2005
>
> Also I am able to debug my release build in VS 2005/VC ++6.0 ( which means I
> have taken care of embedding debug info for my release builds).
>
>
> "Anubhav" wrote:
>
> > I am trying to detect heap memory leaks in my code using UMDH. I get a nice
> > umdh diff log with stacks (+ust setting of gflags) for my debug builds.
> > However when I try the same thing with my release build, I am not getting the
> > proper call stack information for my modules, and in some cases, the logs at
> > the beginning and end are the same (i.e to say that UMDH did not detect any
> > leak).
> >
> > Can some one please help me with what I am doing wrong?

[Ivan Brugiolo [MSFT]]

As it was pointed out in the past, UMDH just displayes stack traces
captured without using any symnbols by NtDll.dll.
The presence of PDB symbols is only needed/required to translated
a captured stack trace to a meaningful chain of function-calls and
line-information,
but, symbols are NOT used to capture stack traces.

This query should give you some background on the problem:
http://groups.google.com/group/microsoft.public.windbg/browse_frm/thread/aecc05a66cf6941f/417d2b0cfd045a4e?lnk=st&q=Incomplete+stack+traces+UMDH+Ivan+Brugiolo&rnum=2#417d2b0cfd045a4e

In a nutshell:
-1- the function that capture stack traces ntdll!RtlWalkFrameChain
does not use symbols.
-2- certain version of msvcrt.dll and other Visual Studio C-Runtimes
might have FPO-optimizations, that simply kill the stack-walker
-3- UMDH is not at fault, it can only resolve symbols that were previousely
captured.

Workarounds:
-1- Use x64/ia64. Stack Walking is always correct on x64/ia64
-2- Use the OS-Supplied C-Runtime in WinXp-Sp2 and/or win2003-sp1.
Those OS-es were compiled FPO-less

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

"Anubhav" <Anu...@discussions.microsoft.com> wrote in message
news:B75A073C-A855-48B2...@microsoft.com...

[Anubhav]

Thanks Ivan. I now have two questions and one suggestion:

Question:

a) what is the recommended way to find CRT based heap memory leaks in a
release build on WinXP SP2 on Pentium platforms?
b) I also expected !heap -l command to give me memory leaks in the code
based on the documenation. But that also does not seem to be giving me any
leaks though I know it is there (in both debug and release builds)

Suggestion:

a) The Documentation for Debugging tools can clearly indicate about the FPO
issues and that the debug CRT or FPOless functions will work perfectly with
UMDH

[Ivan Brugiolo [MSFT]]

# - CRT-Based memory-allocation
-a- you can use the C-Rutnime heap-allocation tracker, and,
you can dump the outstanding blocks that way (you can use
int _CrtDumpMemoryLeaks( void );)
-b- override your global new and delete operator go to HeapAlloc,
and, instruct the compiler to NOT FPO optimize
your implementation of new and delete.
# - `!heap -l`
This command attempts to find heap allocations
that are unreferenced in the address space.
Average C-Rutnime implementation keeps the block in a double-linked list,
so that they are always all referenced, hence not leaked from the point of
view of the heap-mananger.

There are other tools, like LeakDiag,
that perform stack capture using the PDB.
That has other problems, but, in certain cases, it may be more effective.

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

"Anubhav" <Anu...@discussions.microsoft.com> wrote in message

news:385048F6-54DC-4613...@microsoft.com...

[Paul Gusciora]

Where can I find the latest version of LeakDiag? This URL
ftp://ftp.microsoft.com/PSS/Tools/Developer%20Support%20Tools/LeakDiag/ is
referenced in some posts, but the site does not seem to be active.

I see some strange behavior injecting LeakDiag into applications created
with VS2005 C++ and running with the dll's that fix the 2005 CRT memory leak
in std::stringstream. I wanted to update LeakDiag to the latest before I
started looking any more. I have LeakDiag.exe v1.31.3.924 dated 9/4/2003.

Paul Gusciora

BTW: There are not many MSDN articles or pages that have the word LeakDiag
in them.

"Ivan Brugiolo [MSFT]" wrote:
...snip...

>
> There are other tools, like LeakDiag,
> that perform stack capture using the PDB.
> That has other problems, but, in certain cases, it may be more effective.
>

...snip...

[Ivan Brugiolo [MSFT]]

Does this works better ?

ftp://ftp.microsoft.com/PSS/Tools/Developer%20Support%20Tools/LeakDiag/leakdiag125.msi

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

"Paul Gusciora" <PaulGu...@discussions.microsoft.com> wrote in message
news:99B45A5F-8A38-4496...@microsoft.com...