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

[Oswald Buddenhagen]

On Thu, Jan 19, 2006 at 02:49:58PM +0100, Lubos Lunak wrote:
> On Tuesday 17 January 2006 21:03, Oswald Buddenhagen wrote:
> > 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.
> 
errm, well, yes, that's sort of the idea behind it. :)
and maybe it's generally no terribly good idea to auto-restart an app
while it is in "crashing" state - sounds like a potential fork bomb (to
prevent that.

> > - 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,
> 
i'm not thrilled by this idea.

> or you could somehow check if the process still exists.
>
i remember having investigated alternatives.
iirc, wait() & co. don't work, because in ptraced state the process is
reparented (at least with 2.4 kernels; i know something changed a bit
recently, but i'm not sure it was exactly that).
anything else would be a hack ...

well, i already added setSafer() for kdm. maybe we should extend this to
setFlags(), with flags like RestrictedDialog, KeepFilesOpen, and later
maybe more?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.