Re: Call stack

That failure case seems intuitive to me. You can grab the current 
instruction pointer all you want, its just going to change as soon as 
you get it. I ran into a little bit of this with a user threading 
library I wrote once. My guess is you are better off having written the 
25 lines yourself, anyway. And the stack pointer is going to be from 
within the API call, I'd guess.

-Dan

Grills, Jeff wrote:

>I went through three months of harassing MS about this, providing them
>with a sample app that reproduced the problem, and still they didn't
>figure out what the problem was.  And here it is, the real reason, just
>like Dan said:
>
>	if (!GetThreadContext(GetCurrentThread(), &context))
>
>It sure would have been nice it this routine had failed.  Looking at the
>docs for GetThreadContext(), MS claims the following:
>
>	If you call GetThreadContext for the current thread, the
>function returns successfully; however, the context returned is not
>valid.
>
>Nice, an API with a silent failure.
>
>I really need to be able to capture call stacks at runtime from the
>running thread.  We have a warning system used when the game detects but
>recovers from an error (usually caused by faulty data coming from our
>own staff), and call stacks have proven vital to fixing those problems.
>Good thing I broke down and wrote my own routine to capture the call
>stack - it was only 25 lines of code, and much faster than StackWalk,
>too.
>
>j
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of
>Daniel Vogel
>Sent: Wednesday, February 09, 2005 12:50 PM
>To: [email protected]
>Subject: RE: [GD-Windows] Call stack
>
>
>  
>
>>with the SP2 upgrade.  StackWalk won't walk the whole stack - 
>>it just gives up after returning 2 call stack frames.  I've 
>>    
>>
>
>I attached the code of our stack walking implementation (sorry for the
>formatting, notepad didn't like our usage of tabs). It works fine for
>walking the stack after a crash as we have easy access to all the
>information we need to feed StackWalk64.
>
>  
>
>>the stack.  I have plenty of cases in the engine where I 
>>capture a call stack for debugging later if something else 
>>    
>>
>
>IMO StackWalk64 is mostly useless for this case as you cannot call
>GetThreadContext on a running thread.
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b
>ase/getthreadcontext.asp
>
>I assume you're doing this as that's exactly what we did with our proxy
>malloc and it broke with SP2 as well.
>
>-- Daniel, Epic Games Inc.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Gamedevlists-windows mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_idU5
>
>
>  
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555