Getting KCrash & DrKonqi on windows

[Patrick Spendrin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

George Kiagiadakis schrieb:
> Hi guys,
> 
> These days I have been working again on improving KCrash and I also
> had a look again at its windows port that I had started some months
> ago. My findings are encouraging, but there are issues that I need to
> discuss with you.
> 
> First, I'll explain briefly how KCrash works, just to get an idea. The
> KCrash API has a UNIX signal handler that is registered when
> KApplication is constructed. This signal handler has 3 functions:
> 1) It calls an "emergency save function" that the application may
> specify to attempt to save its data.
> 2) It restarts the application, if the application has set the
> KCrash::AutoRestart flag with KCrash::setFlags().
> 3) It launches drkonqi to debug itself and sleeps until drkonqi exits.
> 
> On windows, UNIX signal handlers work (for compatibility) with the
> SIGSEGV, SIGFPE, SIGILL, SIGABRT, SIGTERM and SIGINT signals, but
> probably not on all windows versions (for example docs for VC .NET say
> that SIGSEGV is never signaled on windows, but docs for VC9 say it is,
> and it actually works here on windows 7, but I doubt we can rely on
> it). So, I found another way of doing it, using the windows unhandled
> exception filter (see SetUnhandledExceptionFilter), which looks like
> the same thing as a unix signal handler, but with different arguments.
> So, with a few modifications, the KCrash signal handler works fine.
This could be tested probably with a small application...
> 
> Let's get to DrKonqi now. The code compiles as it is, but requires a
> minor modification to start. It starts gdb to generate a backtrace,
> but gdb fails to generate anything valid. The problems begin here...
> 
> I have been desperately trying to find a debugger that can produce a
> valid backtrace of a crashed process. gdb fails, and so does windbg. I
We should look into that, can you tell where you have testfiles for
that? Normally both debuggers provide us with good backtraces in Debug mode.
> looked into DrMingw, which has some interesting code that uses the
> StackWalk api from dbghelp.dll (imagehlp.dll on other windows
> versions) in combination with libbfd from binutils. I didn't manage to
> compile it, but I am confident that with some hacking it should work.
> I also found StackWalker [1], which is a class that also uses the
> StackWalk api to generate backtraces. It's meant to be run from the
> unhandled exception filter function, but I managed to make it work as
> an external process that attaches to the crashed one with very little
> effort. To my surprise, it generates a valid backtrace (on processes
> that even windbg fails!), but only for applications built with msvc. I
> guess that it needs some glue with libbfd to be able to read the
> symbols from the gcc format.
> 
> That actually means that if we want drkonqi on windows, we need to
> implement our own debugger...! That is not a very trivial task and
> although we can reuse some code from StackWalker (BSD-licensed), I
> believe it will be a quite bigger project than it seems it is. That
> said, I am not really interested in developing such a debugger myself.
Yeah, understandable.
> 
> I would like to hear your opinion on this matter, or any other ideas
> that you may have.
> 
>>From my side, I'll start slowly pushing win32 support in both KCrash
> and DrKonqi. At least, I can make the "emergency save function" and
> auto-restart features work, which is something... However, I'll leave
> drkonqi in the "if (UNIX)" block in CMakeLists.txt so that it's not
> built by default (in that case, KCrash will skip the drkonqi step and
> will just exit).
I think that since we're developing some helper applications ourselves
anyway, also this kind of debugger could be added.
I am not sure about who will have to work on this task, but maybe we can
have a Google Summer of Code student working on that.

I'd love to see the problems myself, so maybe you can tell us where your
code resides, so that more people can take a look at it.
> 
> Regards,
> George
> 
> [1]. http://stackwalker.codeplex.com/
> 
> PS: SetUnhanledExceptionFilter requires windows 2000. Is that OK? Do
> you care about older windows versions?
Yes, code should support to be compiled under windows 2000, nothing
earlier is supported at all, also current packages probably won't work
on 2000 anyway, so that makes it XP.

regards,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (MingW32)

iEYEARECAAYFAkuKy0AACgkQi49rfdk/G3Zv/ACfbFqq3Wxh2XXyvRuJnveafYwp
DF0AoK1h1emqxwly6viUjPVz+xjN8Y74
=VN2I
-----END PGP SIGNATURE-----