Date: Mon, 21 Jul 2003 23:41:14 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: i386@freebsd.org Subject: Re: [-CURRENT tinderbox] failure on i386/i386 Message-ID: <3F1CDC8A.D20F65F@mindspring.com> References: <20030721220459.37E8E2A8B2@canning.wemm.org> <xzpznj778b7.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Sm=F8rgrav wrote: > Peter Wemm <peter@wemm.org> writes: > > Hmm. I thought it was gzip that was dying. Looks like its make instea= d, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F1CDC8A.D20F65F>