More crash-proof KCrash (was Re: Konq crash backtraces)
l.lunak at suse.cz
Wed Jan 11 16:40:43 GMT 2006
On Saturday 07 January 2006 13:13, Lubos Lunak wrote:
> Dne pátek 06 leden 2006 22:31 Thiago Macieira napsal(a):
> > Dik Takken wrote:
> > >It just happened again...
> > >
> > >Konqueror crashed without leaving a single trace. I compiled KDE 3.5
> > > with full debug info, which gives me useful backtraces when a crash
> > > occurs. Konqueror is a weird exception. One of its windows can just
> > > disappear in front of your nose, without DrKonqi popping up to get a
> > > backtrace.
> > >
> > Distributions are shipping glibc with some malloc checks, which cause it
> > to abort the program when a double-free or corruption occurs, but without
> > raising SIGABRT. There must be a way of making glibc raise the signal,
> > but I don't know how. It should be enabled by default in KDE code so that
> > the crash handler can catch them.
> Not really. The error checking does raise SIGABRT, it's just that our
> crash handler depends on malloc() working and locks up already in
> DCOPClient::emergencyClose(). If we want to get a crash handler for heap
> corruptions too, we need to stay away from using the corrupted malloc. I
> can give it a shot.
Ok, it wasn't as trivial, but I have a patch. The changes are:
- no qstrdup() of static strings or actually any strings , no other things
that result in malloc() like using QCString, i18n() or whatever. Results in
some ugly code like KAboutData::translateInternalProgramName() but oh well.
- no DCOPClient::emergencyClose() - what's the point anyway, I'm quite sure it
doesn't get called when I do Ctrl+C and KDE seems to work just fine, so why
should it be called when crashing - it calls malloc() and who knows what else
- no fork() - this one doesn't actually call malloc(), but there are some
functions called at pre-fork time that do something with malloc locks (with
glibc at least) - that leads to lockups as well. Since no fork() means no
executing of other executables, the only other option I see is feeding the
data to some other already running process via a socket. Fortunately we
incidentally have already this kdeinit thingy running that's supposed to
launch executables when it gets told via a socket, so I copy&pasted some code
from there. That means some more syscalls, but that should be still more
safe. There's still a fallback to use fork() in case using kdeinit fails for
This way KCrash should be more reliable and we should (hopefully) always get
DrKonqi now. And I can confirm that after one gets used to DrKonqi just
having an application disappearing without a reason really doesn't feel nice.
I'd like to commit this to 3.5 branch, so it'd be nice if somebody could at
least peek at it.
PS: One more benefit would be that we could now make drkonqi a kdeinit module
in order to make our crashes faster.
PPS: A good way of testing is just doing a double free().
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 16859 bytes
Desc: not available
More information about the kde-core-devel