kcrash, fork, and stdout/stderr

[David Faure]

On lundi 4 décembre 2017 17:04:25 CET Thiago Macieira wrote:
> On Monday, 4 December 2017 00:26:55 PST David Faure wrote:
> > > Or do you fork a child at that point? fork from inside a signal handler
> > > is
> > > an incredibly bad idea, don't do it.
> > 
> > Well, I guess that's why it's the fallback from the main strategy which is
> > "ask kdeinit to restart that application" (even if it doesn't provide a
> > kdeinit module). But kdeinit might not be running, outside plasma
> > workspace.
> > 
> > This has always been like that, it goes back to 2006 (Luboš), it was
> > discussed with you
> > https://marc.info/?l=kde-core-devel&m=113699766611213&w=2 ("There's still
> > a
> > fallback to use fork() in case using kdeinit fails for any reason.")
> 
> Well, I've learnt a lot in the last 11 years.
> 
> forking inside a signal handler is a bad idea because it may deadlock. If
> the crash happens while glibc holds some mutexes relating to
> pthread_atfork, then you'll have a problem.

I see. But how should one implement a crash handler that autorestarts an app, 
then, in a "standalone application" use case, i.e. no kdeinit or other daemon 
running in the background?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5