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
On Sunday, 3 December 2017 02:54:21 PST David Faure wrote:
> I'm trying to fix a bug (caught by CI) where KCrash, with the AutoRestart
> flag, restarts the crashing process directly (fork+execve) rather than via
> kdeinit.
>
> The first process then exits, and whenever the child writes to stderr,
On mardi 5 décembre 2017 16:46:50 CET Thiago Macieira wrote:
> On Tuesday, 5 December 2017 04:12:30 PST David Faure wrote:
> > 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
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
On Tuesday, 5 December 2017 04:12:30 PST David Faure wrote:
> 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?
Wait, why are you forking in the first place?
On lundi 4 décembre 2017 17:04:25 CET Thiago Macieira wrote:
> On Monday, 4 December 2017 00:26:55 PST David Faure wrote:
> > > 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
On Monday, 4 December 2017 00:26:55 PST David Faure wrote:
> > 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
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
On Sunday, 3 December 2017 12:12:53 PST David Faure wrote:
> > This should already work, unless the O_CLOEXEC flag has been set on the
> > file descriptor for stderr. The kernel should duplicate open
> > descriptors on fork(2), and exec(2) should maintain its association to
> > any already-open
On dimanche 3 décembre 2017 17:17:10 CET Michael Pyne wrote:
> On Sun, Dec 03, 2017 at 11:54:21AM +0100, David Faure wrote:
> > I'm trying to fix a bug (caught by CI) where KCrash, with the AutoRestart
> > flag, restarts the crashing process directly (fork+execve) rather than
> > via kdeinit.
> >
On Sun, Dec 03, 2017 at 11:54:21AM +0100, David Faure wrote:
> I'm trying to fix a bug (caught by CI) where KCrash, with the AutoRestart
> flag,
> restarts the crashing process directly (fork+execve) rather than via kdeinit.
>
> The first process then exits, and whenever the child writes to
I'm trying to fix a bug (caught by CI) where KCrash, with the AutoRestart flag,
restarts the crashing process directly (fork+execve) rather than via kdeinit.
The first process then exits, and whenever the child writes to stderr, it gets
a SIGPIPE. Oops.
How do I set things up so that the
12 matches
Mail list logo
