On Fri, 09 Nov 2007 18:59:50 -0500, Alain wrote:


> There are times when you can't do a stack backtrace because the stack
> have been corrupted. Something like a bad vector that send you to a bit
> of code that call a subprocess, pushing the return address on the stack,
> and the code pointed to ask tou to jump the another subprocess, whitch
> is itself. Infinite loop causing a stack overflow, and in some cases,
> the stack cycling pointer cycling back to zero. Or you enter a loop that
> pop data out of the stack until there is no more data to retreive, and
> the stack pointer jump to the largest value it can contain. There are
> times when the crash can cause corruption far outside the area that a
> process is allowed to access.

Absolutely this can happen.  In my experience, it's not terribly common, 
but sure, ESP and EBP can contain invalid values which can make it ugly 
or impossible to diagnose.  These situations are the exception (pun not 
intended) rather than the rule.

>> I watched one engineer do live debugging of a client issue on a Windows
>> system; watching someone use a tool like that who knows what they're
>> doing is a very interesting thing, because they can pull information
>> about what's going on at any given point in the process.  Doing it live
>> or doing it from a core file is pretty similar, except that with a core
>> file the system isn't changing; it's actually the *easier* way to
>> debug, because you're working from a snapshot of a program at a point
>> in time instead of watching things change.
> Easier to look at a snapshot than to the changes. The snapshot is
> frozen. If you try to look as it changes, it's usualy to fast.

Yes, a snapshot is easier.  Fortunately, if you're doing "live" 
debugging, you do have the opportunity to halt things and look at the 
state, and then single step over or through functions.  That doesn't help 
if the issue is a timing issue, but those can be the most difficult to 
nail down.

Having access at the kernel level, you can do all kinds of neat things.

Jim

Post a reply to this message