kcrash, fork, and stdout/stderr
David Faure
faure at kde.org
Mon Dec 4 08:26:55 UTC 2017
On lundi 4 décembre 2017 05:43:14 CET Thiago Macieira wrote:
> > Yes, no kdeinit involved. Here's the setup:
> >
> > $ bin/kcrashtest testAutoRestartDirectly
> >
> > starts test_crasher (with QProcess, using waitForFinished())
> >
> > which crashes :)
> > KCrash catches that, and since the Autorestart flag is set,
> >
> > sets the env var KCRASH_AUTO_RESTARTED,
> > and starts test_crasher again (it checks that env var, so no
> >
> > infinite loop)
> >
> > The first test_crasher then exits (after waitpid(), but that's just
> > waiting
> > for the child to start, right?).
>
> Sorry, more details here. Can you provide the strace for clone, pipe, pipe2,
> dup, dup2, dup3, execve, waitpid, waitid, wait4?
>
> QProcess starts a process.
>
> Does that process start something else? Or is QProcess's direct child that
> crashes?
It's exactly as I described. It's QProcess's direct child which crashes
(and which has a segv handler enabled, KCrash).
> The crash handler is in-process, correct? Then you execve in place?
fork+execve
https://lxr.kde.org/source/frameworks/kcrash/src/kcrash.cpp#0733
> 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.")
> That makes QProcess not create a pipe and instead pass its own stderr to the
> child. Then it's SEP.
Yep, so from my POV the problem is fixed.
Thanks for the additional input!
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
More information about the Kde-frameworks-devel
mailing list