Re: [-CURRENT tinderbox] failure on i386/i386

Dag-Erling Smørgrav wrote:
> Peter Wemm <peter_at_wemm.org> writes:
> > Hmm. I thought it was gzip that was dying. Looks like its make instead, and
> > is rather consistent.
> 
> "told you so"
> 
> > So, who has been messing with make(1) lately?
> 
> I believe that the problem is in the kernel, not in make(1); it just
> happens to be triggered by make(1) because it is a big (if not the
> biggest) vfork(2) consumer.

It's pretty evil, too.  It makes all sorts of system calls that
it ought not to be making (i.e. it's permitted to call execve(2)
or _exit(2), and that's all, period: all other system calls have
undefined behaviour, according to the standards).

It's really *very* tempting to set up a "vfork(2) system call
table" that has only those two system calls in it, and returns
"ENOSYS" for everything else, to catch the idiots who think that
"vfork() is just like fork(), only faster".

Most likely, it's hitting a race in dup2(2) or write(2) or close(2)
or one of the other system calls it calls between the vfork(2) and
the execve(2)/_exit(2).

-- Terry