More crash-proof KCrash (was Re: Konq crash backtraces)
ossi at kde.org
Thu Jan 19 17:19:19 GMT 2006
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
> > - 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
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the kde-core-devel