RE: [GD-Windows] Call stack

[Jon W. <hp...@mi...>]

Replying to multiple replies here...


First: I ran the code I just posted on XP2 right before I posted
it. No OS update should make the EBP linkage any different -- that
would ruin the semantics of a compiled program. I take it from
your other comments that you really mean you're using the Microsoft
StackWalk function?


Second: I don't think CreateMiniDump is the right solution for the
initial problem the poster has, because he wanted a trace from each
and every call to his random routine, to compare the pattern in two
different run cases. Creating one minidump per random number
generated would sort-of crimp your interactivity :-)


Third: If you can't get the walking list to work, you can also scan
each aligned pointer word on the stack and see whether it points
at a return address. To do that, you first take the address and
compare to the executable image range of all loaded modules; if
it's in one of those, you can call a function like this:

You may get some false positives if you have sparse stack usage,
like declaring a char path[1024] in the middle of your stack
frame.


// Value is a pointer into what's known to be a code segment.
// Return TRUE if value would be the return address put on
// the stack by a function/method call.
bool
AddressRange::isReturnAddress( ptrdiff_t value )
{
  unsigned char const * ptr = (unsigned char const *)value;
  return (ptr[-5] == 0xe8) ||                 //  CALL xxxxx
    (ptr[-6] == 0xFF && ptr[-5] == 0x15) ||   //  CALL DWORD PTR xxxxx
    (ptr[0] == 0x83 && ptr[1] == 0xc4);       //  ADD ESP, imm8
}


Cheers,

            / h+

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Grills, Jeff
Sent: Wednesday, February 09, 2005 9:48 AM
To: gam...@li...
Subject: RE: [GD-Windows] Call stack


I have very similar code for walking the stack.  My code works on many
versions of windows, but it has stopped working as of Windows XP SP2.  I
even did a test on a machine where my test program worked, I upgraded to
SP2, and the test program stopped working, so I know it had something to do
with the SP2 upgrade.  StackWalk won't walk the whole stack - it just gives
up after returning 2 call stack frames.  I've ended up having to rewrite
StackWalk myself (which isn't very hard, if you disable the "Frame pointer
omission" optimization, since you can use the EBP register to walk up the
stack).  I've complained to Microsoft about this, but they haven't been very
quick to try and fix it.  Anyone else run into the same problem on XP SP2?
If it's just me, then I'll start comparing my code against other
implementations (like the one below) to see what I may doing wrong.  If it's
not just me, I'd be happy to share my stack walking code so that others can
work around the issue..

One thing I do differently than most other implementations I've seen is that
I don't do any symbol lookup while walking the stack.  I have plenty of
cases in the engine where I capture a call stack for debugging later if
something else goes wrong, and the symbol lookup may not be necessary.  For
instance, our memory manager can grab a stack for every allocation, and at
application exit time we can report the call stack for any memory leaks.
Typically all allocations are properly freed, so looking up the symbols when
capturing the call stack during an allocation is unnecessary and also
seriously impacts performance.  In the rare case of a memory leak (most
often discovered in new code that hasn't been submitted), very few addresses
need to be translated into symbols.

Jeff Grills
Senior Technical Director, Austin Studio
Sony Online Entertainment
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Simon
O'Connor
Sent: Wednesday, February 09, 2005 7:58 AM
To: gam...@li...
Subject: Re: [GD-Windows] Call stack



I wrote some code a while back that sounds like what you're after - or at
least should point you in the right direction:
http://www.sc3d.com/thought/snippets/debugging/GetFunctionCaller/
NB: It's not quite what I'd class as "production" quality - it was written
for debugging purposes only :o)
Cheers,

Simon O'Connor
Programmer @ Reflections Interactive
& Microsoft DirectX MVP