kcrash, fork, and stdout/stderr

Oswald Buddenhagen oswald.buddenhagen at qt.io
Tue Dec 5 12:19:21 UTC 2017


On Tue, Dec 05, 2017 at 01:12:30PM +0100, David Faure wrote:
> On lundi 4 décembre 2017 17:04:25 CET Thiago Macieira wrote:
> > 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?
> 
you don't ...
the fail-safe solution would be forking right after start, basically
having a privately owned mini-kdeinit. but that seems like major
overkill. the crash handler (and even more auto-restart) are
nice-to-have features, so it seems reasonable that they don't work
reliably outside a kde session.


More information about the Kde-frameworks-devel mailing list