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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5