bt in traces

Eric Pouech pouech-eric at
Thu Feb 19 14:39:38 CST 2004

Robert Shearman a écrit :
> Mike Hearn wrote:
>>On Wed, 2004-02-18 at 19:49, Eric Pouech wrote:
>>>this would be as intrusive as using the debugger (I assume that the
>>>running process would be in charge of printing the backtrace, or an
>>>external process - like a debugger - would print the backtrace, while
>>>the program is stopped (or after copying the stack for instrospection,
>>>which dbghelp doesn't provide btw))
>>Why would it be intrusive? Can't you just take a snapshot of the stack
>>and walk it internally? That must be what StackWalk does, right, as apps
>>often try and grab their own backtraces....
> You're right that it wouldn't be intrusive (just like Linux kernel
> backtraces in the kernel log). However, StackWalk doesn't do exactly what
> you think it does. It generates frame pointer information (including the
> instruction pointer), but you need to call it recursively. Even then it
> won't be very readable unless you put in symbol lookups. Very soon you have
> completed one of the todo's by moving most of winedbg into imagehlp/dbghlp.
the point is that even just taking the snapshot of the stack *is* 
intrusive, however you do it.
Morever, there are a couple of _interesting_ corner cases:
- just taking a snapshot of the stack isn't enough: you need to resolve 
symbols from addresses, which depend on the loaded modules at the time 
you take the snapshot. Which means that either you load module 
information when modules are loaded (intrusive too), and when you want 
to do the stack snapshot (also intrusive)
- finally, you end up using 80% of the core functions of a debugger

perhaps the easiest way to implement what you want would be to create a 
specific exception (like wine_stack_walk). This exception would be very 
close to the one for undefined symbols. You would insert throwing this 
except in the places you want in your code, and winedbg would react to 
it by printing the stack backtrace of current thread and continue 
execution (we could also extend this as a specific kind of breakpoint, 
to be set in the debugger)


More information about the wine-devel mailing list