Ah, ok! Thanks for clearing that up Rasmus! :o)

And thanks again everyone for helping out. Everything runs fine for me now!

Best Regards
Stefan Nilsson

On Wed, Jan 3, 2018 at 11:09 AM, Rasmus Villemoes <
rasmus.villem...@prevas.dk> wrote:

> On 2018-01-03 01:13, Steffe - wrote:
>
> > I tested now with s6-rc version 0.3.0.0 and skalibs 2.6.0.1 and the
> SIGFPE
> > is gone. If I just run everything it seems to work OK. But when I tried
> to
> > run it through Valgrind I did get an assert, but I don't know if that
> might
> > be related to valgrind or not. The output is here:
> > http://steffe.net/s6/valgrind_skalib_2.6.0.1.txt
>
> That's unrelated to s6. Incidentally, that assert() in glibc was
> introduced by me, but it is wrong in case the newly spawned process is
> killed by somebody sending random signal to random pids (nobody knows
> the pid of the new process until the parent runs, which it won't do
> until the child has actually made the assertion true, so nobody has any
> business sending a signal that way). Anyway, the assert has since been
> removed, but that probably hasn't made it to a release yet.
>
> Normally, you'd never trigger this assert except for the
> sending-lethal-signals-to-random-pids. However, valgrind's clone()
> replacement doesn't support the CLONE_* combination used to implement
> posix_spawn (sharing memory between parent and child, yet being
> different processes), so the assert() will trigger consistently for any
> program using posix_spawn and a recent enough glibc. I'm not sure
> whether valgrind works after the assert has been removed - it's possible
> that it works fine in the normal case where all the spawn actions and
> the execve succeed, but in case the child needs to report an error (e.g.
> simply execve failing with ENOENT), that error reporting won't work
> under valgrind.
>
> In case you want to debug skaware programs under valgrind and are stuck
> with glibc 2.26, I think you should be able to simply update the sysdeps
> to pretend posix_spawn is not available.
>
> Rasmus
>

Reply via email to