I need some app that will produce a crash in order to test winedbg and get used to it. Does anybody have such an application or can tell me a quick way how to create one? Except booting to Windows and writing a NULL pointer access or some such. :) I installed winedbg according to the winehq instructions but when Agent crashes and I say Yes to debug it the wineserver and agent is stuck and I have to kill -9 it. Maybe this is because the output goes to the console window? I think I read something about console but I have no console as a normal user so I can't check this. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
Gerhard W. Gruber wrote:
I need some app that will produce a crash in order to test winedbg and get used to it. Does anybody have such an application or can tell me a quick way how to create one?
As a naive usr, I would think each of the lines in main of the following should do it: #include <stdio.h> #include <assert.h> #include <signal.h> #include <stdlib.h> int main(int argc, char **argv) { int *p = 0; *p = 7; abort(); raise(SIGILL); assert(0); } but in practice, only the bad pointer access does. For some reason, raise(), assert(0), and abort() fail to trigger the debugger. You can compile this easily with mingw or msvc running under wine. (I did it with msvc.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <dank(a)kegel.com> wrote:
but in practice, only the bad pointer access does. For some reason, raise(), assert(0), and abort() fail to trigger the debugger.
You can compile this easily with mingw or msvc running under wine. (I did it with msvc.)
Thanks. I have neither installed, so it would be faster for me to reboot. :) Anyway I just managed to fire the debugger. As I understood the winehq instruction I thought that winedbg will be fired as soon as an exception occurs, just like in windows when Visual Studio is installed (or any other debugger for that matter). But this doesn't work for me, or I missunderstood it. Now I tried running agent directly from within winedbg and this works so far. I still have to get accustomed to these tools, though. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
"Gerhard" == Gerhard W Gruber <sparhawk(a)gmx.at> writes:
Gerhard> On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <dank(a)kegel.com> Gerhard> wrote: >> but in practice, only the bad pointer access does. For some reason, >> raise(), assert(0), and abort() fail to trigger the debugger. >> >> You can compile this easily with mingw or msvc running under wine. >> (I did it with msvc.) Gerhard> Thanks. I have neither installed, so it would be faster for me Gerhard> to reboot. :) Anyway I just managed to fire the debugger. As I Gerhard> understood the winehq instruction I thought that winedbg will Gerhard> be fired as soon as an exception occurs, just like in windows Gerhard> when Visual Studio is installed (or any other debugger for that Gerhard> matter). But this doesn't work for me, or I missunderstood Gerhard> it. Now I tried running agent directly from within winedbg and Gerhard> this works so far. I still have to get accustomed to these Gerhard> tools, though. :) Why nor write Dan's example a ../dll/kernel/test/xx file? No windows compiler needed. But don't make run by default :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Well, there are easier ways :) Just run an app in winedbg, then press ctrl-c to halt it. Then do "bt" to get a backtrace. You'll be able to move up and down the stack frames, inspect local variables and see the source (inside wine code). You can also do disassembly inside closed source stuff, but I'm not elite enough to show you how to do that. Mostly wine debugging is simply a matter of looking at the logs and doing some logical deduction. I once considered making a wine developers beginners guide that goes through some known bugs in a release with some free apps etc but never got around to it. Having said that you may hit lucky like I did and find the first bug you try and fix is relatively easy (a dud message param in my case) or it may be ridiculously hard, like the current ones I'm chasing in RhymBox which does all kinds of funky things with embeddeding IE. Just keep plugging away at it, you'll be fine :) On Tue, 2003-02-25 at 21:41, Gerhard W. Gruber wrote:
On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <dank(a)kegel.com> wrote:
but in practice, only the bad pointer access does. For some reason, raise(), assert(0), and abort() fail to trigger the debugger.
You can compile this easily with mingw or msvc running under wine. (I did it with msvc.)
Thanks. I have neither installed, so it would be faster for me to reboot. :) Anyway I just managed to fire the debugger. As I understood the winehq instruction I thought that winedbg will be fired as soon as an exception occurs, just like in windows when Visual Studio is installed (or any other debugger for that matter). But this doesn't work for me, or I missunderstood it. Now I tried running agent directly from within winedbg and this works so far. I still have to get accustomed to these tools, though. :)
On 25 Feb 2003 21:54:24 +0000, Mike Hearn <mike(a)theoretic.com> wrote:
Just run an app in winedbg, then press ctrl-c to halt it. Then do "bt" to get a backtrace. You'll be able to move up and down the stack frames,
I noticed that. :) Convinient because it is similar to gdb, but I couldn't get gdb compatibillity to work. On the website it says to add -gdb to winedbg but it complains about that. I think I can get used to it anyway. :)
inspect local variables and see the source (inside wine code). You can also do disassembly inside closed source stuff, but I'm not elite enough to show you how to do that.
No problem with that. I was doing asm more than ten years because it is a hobby of mine. :)
Mostly wine debugging is simply a matter of looking at the logs and doing some logical deduction. I once considered making a wine developers beginners guide that goes through some known bugs in a release with some free apps etc but never got around to it.
If this would be a tutorial for winedbg this would be really helpfull, but I think I can get started now once that I managed to fire it and get some information out of it. :) The only thing I'm not used to is the Unix syntax for disassembling. I'm more used to the intel syntax like it is used in Windows debuggers. I once wrote a disassmebling class for myself. Would there be some interest in including that in winedbg in order to be able to switch between Intel and Unix style disasm?
may be ridiculously hard, like the current ones I'm chasing in RhymBox which does all kinds of funky things with embeddeding IE.
I can imagine that. My first goal is to get agen stable and then I think I will focus more on games. This is the area that I really miss from Windows and is the only thing that requires me to have a windows partition to keep around. Currently I don't have that much time, though, because I'm moving so it will still take some weeks until I can dig really more into wine. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
"Gerhard" == Gerhard W Gruber <sparhawk(a)gmx.at> writes:
Gerhard> On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <dank(a)kegel.com> Gerhard> wrote: >> but in practice, only the bad pointer access does. For some reason, >> raise(), assert(0), and abort() fail to trigger the debugger. >> >> You can compile this easily with mingw or msvc running under wine. >> (I did it with msvc.) Gerhard> Thanks. I have neither installed, so it would be faster for me Gerhard> to reboot. :) Anyway I just managed to fire the debugger. As I Gerhard> understood the winehq instruction I thought that winedbg will Gerhard> be fired as soon as an exception occurs, just like in windows Gerhard> when Visual Studio is installed (or any other debugger for that Gerhard> matter). But this doesn't work for me, or I missunderstood Gerhard> it. Now I tried running agent directly from within winedbg and Gerhard> this works so far. I still have to get accustomed to these Gerhard> tools, though. :) (This time with a little review before hitting the send buttom :-( ) Why not write Dan's example as a ../dll/kernel/test/xx file? No windows compiler needed. But don't make run by default :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
participants (4)
-
Dan Kegel -
Gerhard W. Gruber -
Mike Hearn -
Uwe Bonnes