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@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. :)