Is there some test app that reliable crashes?

[Mike Hearn]

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