More crash-proof KCrash (was Re: Konq crash backtraces)

[Lubos Lunak]

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 
any reason.

 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().

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
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...
Name: kdecore.patch
Type: text/x-diff
Size: 16859 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060111/cc70bb73/attachment.patch>