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