kcrash, fork, and stdout/stderr

[Thiago Macieira]

On Tuesday, 5 December 2017 04:12:30 PST David Faure 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?

Use syscall(SYS_clone) instead of fork(). The system call always works, it's 
glibc's fork() internals that are known to have problems.

Linux-only, of course.

>From forkfd.c:

        /* start the child - can't use fork() because it may deadlock */
#if defined(__NR_clone2)
        child_pid = syscall(__NR_clone2, SIGCHLD, NULL, 0, NULL, NULL, NULL);
#elif defined(__cris__) || defined(__s390__)
        child_pid = syscall(__NR_clone, NULL, SIGCHLD, NULL, NULL, 0L);
#else
        child_pid = syscall(__NR_clone, SIGCHLD, NULL, NULL, NULL, 0L);
#endif
        if (child_pid == 0) {
            /* child process - restore state */

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center