Re: Detecting stack corruption

From:

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 20 Feb 2007 20:10:13 -0800

Message-ID:

<#2o0w4WVHHA.1432@TK2MSFTNGP02.phx.gbl>

better_cs_now@yahoo.com wrote:

Hello all,

Our application hangs with 0% CPU usage. When I "Break All", I see a
very short call stack for our main thread (much shorter than it should
be) - only the top few entries are shown. My experience has always
been that this inidctates stack corruption. I have directed the
debugger to break as soon as an exception is thrown. This has been
done for all exceptions, in particular "Stack memory corruption" under
"Native run-time checks". However, this is not catching the problem.
We have a very large application with many threads, so it's like
hunting for a needle in a haystack. Furthermore, procurring
BoundsChecker has been quashed from above. So, I'd like to solicit
alternatives on how to track down the point at which the stack is
first corrupted.

Is this on a release build? Can you reproduce it on a debug build? Do the
frames that do appear in the stack listing look reasonable, or is it
nonsense? Are you compiling with /GS and /GZ?

Note that if you're looking at a release build, a short stack frame is not
necessarily indicative of anything other than a routine in which the
compiler used the "omit frame pointer" optimization, thus breaking the chain
of EBP values that makes up the native stack frame chain.

-cd