Hi Is it possible to output the backtrace while the program is running? I mean that with a new debug command e.g. wine_dbg_bt or so you could output not only the name of the called function and the argument values (as with the debug channels) but also the call stack where it came from. That's of course only temporarily for debugging inside wine. If I see that a function has a problem because the argument is wrong it would be much easier to find out where this came from. If I only want to use it inside wine it should have access to the call stack information, no? Thanks bye Fabi
why can't you Just use a debugger? Fabian Cenedese wrote:
Hi
Is it possible to output the backtrace while the program is running? I mean that with a new debug command e.g. wine_dbg_bt or so you could output not only the name of the called function and the argument values (as with the debug channels) but also the call stack where it came from. That's of course only temporarily for debugging inside wine. If I see that a function has a problem because the argument is wrong it would be much easier to find out where this came from. If I only want to use it inside wine it should have access to the call stack information, no?
Thanks
bye Fabi
Is it possible to output the backtrace while the program is running? I mean that with a new debug command e.g. wine_dbg_bt or so you could output not only the name of the called function and the argument values (as with the debug channels) but also the call stack where it came from. That's of course only temporarily for debugging inside wine. If I see that a function has a problem because the argument is wrong it would be much easier to find out where this came from. If I only want to use it inside wine it should have access to the call stack information, no?
why can't you Just use a debugger?
One thing is that I have a problem with breakpoints, winedbg just rushes through as explained here: ... hmm, can't access winehq again. Mail was "WineDbg didn't stop" from 22.01.2004. But besides that: I like to have the full picture of what was going on, from program start to end. And it could also be that a function was called differently on different occasions. (If there was only one possibility a simple grep would give me the answer). So a log with some call stacks would be nice. But if this is too complicated then ok, I just thought that would be a usefull tool. bye Fabi
On Wed, 18 Feb 2004 11:19:10 +0100, Fabian Cenedese wrote:
But besides that: I like to have the full picture of what was going on, from program start to end. And it could also be that a function was called differently on different occasions. (If there was only one possibility a simple grep would give me the answer). So a log with some call stacks would be nice. But if this is too complicated then ok, I just thought that would be a usefull tool.
Yeah, I've occasionally wanted something like this. Running an app in a debugger can change its behaviour whereas logging typically does so less often - the way to do this would be to implement imagehlp.StackWalk, which means moving code out of winedbg into this DLL then making winedbg use it. We could then have a utility helper which uses StackWalk to print out a backtrace to a debug channel. thanks -mike
Mike Hearn a écrit :
On Wed, 18 Feb 2004 11:19:10 +0100, Fabian Cenedese wrote:
But besides that: I like to have the full picture of what was going on, from program start to end. And it could also be that a function was called differently on different occasions. (If there was only one possibility a simple grep would give me the answer). So a log with some call stacks would be nice. But if this is too complicated then ok, I just thought that would be a usefull tool.
Yeah, I've occasionally wanted something like this. Running an app in a debugger can change its behaviour whereas logging typically does so less often - the way to do this would be to implement imagehlp.StackWalk, which means moving code out of winedbg into this DLL then making winedbg use it. 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)) Fabi (another thought), did you try to add DbgBreak(); in the function itself and use bt in the debugger ? A+
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....
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. Rob
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) A+
On Thu, 19 Feb 2004, Eric Pouech wrote:
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)
Bu if there is already an official MS DLL for doing that, why go though all this trobule? Shouldn't we move most of the debugger in there, and build the debugger on top of it? -- Dimi.
Dimitrie O. Paun a écrit :
On Thu, 19 Feb 2004, Eric Pouech wrote:
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)
Bu if there is already an official MS DLL for doing that, why go though all this trobule? Shouldn't we move most of the debugger in there, and build the debugger on top of it?
sure (I mentionned it already a couple of times) but this will be nevertheless intrusive (and as already pointed out, as the dbghelp API is designed, the thread must be disabled the whole time of stack walking, which makes it a bit more intrusive A+
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)) Fabi (another thought), did you try to add DbgBreak(); in the function itself and use bt in the debugger ?
That may work (I haven't tried) but would only be useful for some cases. The one where it didn't stop on the bp would be one. But there are others. If I want to look at a function which is called many times (hundreds) and I'm only interested in the one time it fails I don't want to 'cont' as many times. Second is that winedbg catches every exception, handled or not. For a small test program this is no problem. But for bigger real life apps with exceptions and internal handling this makes them almost unusable. Always falling back to winedbg and 'pass' or 'cont' is not really running a program. Winedbg is ok, I also use it when I can. But most of the time debug logs (with some own messages) are more helpful to me. bye Fabi
participants (6)
-
Boaz Harrosh -
Dimitrie O. Paun -
Eric Pouech -
Fabian Cenedese -
Mike Hearn -
Robert Shearman