Dag-Erling Smørgrav wrote: > Peter Wemm <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"