Robert Shearman rob@codeweavers.com writes:
I propose the addition of this new debug tool that will allow developers to output backtraces to the console, without having to interact with a debugger. It can give a useful indication of how functions are being called in situations where a break point is not appropriate.
I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue.
On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue.
I am not 100% how the patch that Robert's proposing would work in practice, but I can tell you (from working with Java for a long time now) that having readily available backtraces is invaluable.
I for one love backtraces, but on the other hand I don't much care for debuggers. Having access to them without being forced to go through the debuger would be much appreciated.
Hi,
On Wed, Aug 18, 2004 at 12:22:50AM -0400, Dimitrie O. Paun wrote:
On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue.
I am not 100% how the patch that Robert's proposing would work in practice, but I can tell you (from working with Java for a long time now) that having readily available backtraces is invaluable.
I for one love backtraces, but on the other hand I don't much care for debuggers. Having access to them without being forced to go through the debuger would be much appreciated.
Dito. Wine has always had massive problems with getting easily accessible debugging/diag support (doing debugging stuff IS hard, no question here...). Thus I think we generally want not less, but more support, as long as it helps (and as long as it doesn't cause a maintenance headache or ill-maintained subsystems due to too much "choice" in debugging options...). Since I'd think that that backtrace code should be fairly small and self-maintaining, I'd vote for including it.
Me too! *jumps up and down* In Java you can say this:
new Exception().printBackTrace();
or some equivalent to get a printout of where you are, and it's very convenient.
I can see the reasoning behind keeping the code in the debugger then triggering it using a custom exception though, as that way we only have one piece of backtracing code.
My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough!
Wine has always had massive problems with getting easily accessible debugging/diag support (doing debugging stuff IS hard, no question here...). Thus I think we generally want not less, but more support, as long as it helps (and as long as it doesn't cause a maintenance headache or ill-maintained subsystems due to too much "choice" in debugging options...). Since I'd think that that backtrace code should be fairly small and self-maintaining, I'd vote for including it.
Hi,
On Wed, Aug 18, 2004 at 09:27:53AM +0100, Mike Hearn wrote:
My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough!
Indeed. I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...
That's why a "no frills" debugging mechanism is a good idea IMHO.
Andreas Mohr
P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)
Andreas Mohr wrote:
P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)
Yes, without his work this patch would have been impossible. A lot of the debugger has now been moved into dbghelp so that it can be used by other things than just the debugger.
Rob
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...
Well, I can also imagine a lot of cases where the in-process backtrace won't work right, the main one being that since the code will never be used unless you want a backtrace, when you try to use it you'll realize that it no longer works, or doesn't even compile anymore. If we call the debugger instead, it will use the standard backtrace code which is always compiled in, and regularly used by a lot of people.
Alexandre Julliard wrote:
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...
Well, I can also imagine a lot of cases where the in-process backtrace won't work right, the main one being that since the code will never be used unless you want a backtrace, when you try to use it you'll realize that it no longer works, or doesn't even compile anymore. If we call the debugger instead, it will use the standard backtrace code which is always compiled in, and regularly used by a lot of people.
Do you want me to write a unit test that uses it then?
Rob
Robert Shearman rob@codeweavers.com writes:
Alexandre Julliard wrote:
Well, I can also imagine a lot of cases where the in-process backtrace won't work right, the main one being that since the code will never be used unless you want a backtrace, when you try to use it you'll realize that it no longer works, or doesn't even compile anymore. If we call the debugger instead, it will use the standard backtrace code which is always compiled in, and regularly used by a lot of people.
Do you want me to write a unit test that uses it then?
No, the backtrace should be done by the debugger.
On Wed, 18 Aug 2004 13:13:13 -0700, Alexandre Julliard wrote:
No, the backtrace should be done by the debugger.
So for this functionality you want a custom exception with a vectored handler?
Mike Hearn mike@navi.cx writes:
So for this functionality you want a custom exception with a vectored handler?
A custom exception yes; there's no need for a vectored handler, the whole point is to use the normal mechanism so that the exception gets to the debugger.
On Thu, 2004-08-19 at 17:02 -0700, Alexandre Julliard wrote:
A custom exception yes; there's no need for a vectored handler, the whole point is to use the normal mechanism so that the exception gets to the debugger.
This isn't reliable though, what about apps that swallow all exceptions with a try/except block? Ideally you want this sort of thing to just work and not have to figure out why your backtrace is never happening.
Mike Hearn mike@navi.cx writes:
This isn't reliable though, what about apps that swallow all exceptions with a try/except block? Ideally you want this sort of thing to just work and not have to figure out why your backtrace is never happening.
In that case you have to start the debugger first. Of course there will be cases where it won't work as well as you'd like, you'll have the same with the in-process solution, there are many cases where it won't work. And actually the debugger solution has more chances to work reliably since being in a separate process it interferes much less with the running application.
Indeed. I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...
That's why a "no frills" debugging mechanism is a good idea IMHO.
Andreas Mohr
P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)
No offense taken. If I look to your list of potential issues, most of them fall into Alexandre's private garden... <g> A+
-
Alexandre Julliard -
Andreas Mohr -
Dimitrie O. Paun -
Eric Pouech -
Mike Hearn -
Mike Hearn -
Robert Shearman