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

Lubos Lunak l.lunak at
Thu Jan 19 13:49:58 GMT 2006

On Tuesday 17 January 2006 21:03, Oswald Buddenhagen wrote:
> On Tue, Jan 17, 2006 at 01:36:30PM +0100, Lubos Lunak wrote:
> > > It's called to free up the dcop name while the crash dialog is
> > > showing. It also allows kicker to restart from the crash handler.
> >
> > I guess it pre-dates the closing of all open filedescriptors done in
> > the crashhandler. Kicker restarts here just fine and the dcop
> > connection is broken by the close() too.
> fwiw, i have the attached patch on my disk for something like 1 - 1½
> years. it's particularly remarkable that it closes only the dcop and x
> connection in the parent, then forks off the process for drkonqi and
> closes the file descriptors only in the child. the idea is to keep the
> handles open, so a parent process that determines the child's state
> based on some pipes would not bury the process until drkonqi diagnosed
> death

 That seems to be a rather rare case. Not closing all file handles on the 
other hand could prevent e.g. restarting of those applications. IMHO it's 
better the way it is.

> - in kdm's case that means resetting the x-server, so drkonqi 
> wouldn't have a particularly long appearance otherwise.

 I think you should consider this to be a special case and handle it 
specially. Since handles 0-2 aren't closed, as an ugly hack you could dup2() 
the handle you need in the application-supplied function for KCrash, or you 
could somehow check if the process still exists.

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at , l.lunak at
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

More information about the kde-core-devel mailing list