Re: full moon, vm status update

[Andy Wingo]

Hi,

On Thu 16 Oct 2008 07:35, "Julian Graham" <address@hidden> writes:

>>    My current speculation is that when you compile --with-threads, as I
>>    do, that the socketpair between the signal receiving thread and the
>>    main thread is not closed after the fork, therefore signals in the
>>    child might reach the parent or vice versa, causing random code to
>>    run which itself might cause VM problems.

This loopy speculation was only part-right: it *was* async handling that
was causing tests with compiled popen.scm to fail, because we didn't
save the registers before running the asyncs. I have now fixed that.

But it does not appear to have been related to the socketpair.

> Well, yes, that's possible; the signal handling system certainly isn't
> aware of forking.  But since only the thread calling fork() gets
> created in the child process (and the signal delivery thread should
> never fork), errant signal propagation would only be one-way -- in the
> child-to-parent direction.

Ah yes, good point. Still sounds like a bug though.

    scheme@(guile-user)> (sigaction SIGINT (lambda (x) (pk x (getpid))))
    $1 = (#<program #(3361 48 boot-9.scm) (sig)> . 268435456)
    scheme@(guile-user)> (define (fork-sleep-int)
                           (primitive-fork)
                           (pk 'after-fork (getpid))
                           (sleep 2)
                           (raise SIGINT))
    scheme@(guile-user)> (fork-sleep-int)

    ;;; (after-fork 878)

    ;;; (after-fork 932)
    scheme@(guile-user)> 
    ;;; (2 878)
    scheme@(guile-user)> scheme@(guile-user)> 

    ;;; (2 878)
    scheme@(guile-user)> 

You might have to press enter a couple of times to get the second pk to
come through, I think. It seems fork + signal handling is borked with a
guile compiled --with-threads -- and that's not specific to the vm
branch.

> I think I'm missing a little context, though. Is forking (without
> doing an execve) something that happens during compilation of VM code?

No, I'm just running Guile's test suite with a compiled ice-9.
Socket.test does fork without exec, but even with an exec the fd table
is kept the same iirc.

> What should the behavior be in this situation? If the child process
> doesn't need async support, I guess it could close the write end of
> the signal pipe, but that seems... wrong, somehow.

Well, in popen.scm, we already close all of the fd's that guile knows
about in the child process. So it looks like in the popen case we're
just missing one, if my suspicions are right. Then in a Guile child, we
should probably re-spawn the thread to handle signals? I have no idea
here.

An interesting bug, eh. Who wants to fix it? (Ludo? :-)

Andy
-- 
http://wingolog.org/