From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 23:42:32 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AE4B37B401; Mon, 21 Jul 2003 23:42:32 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A562D43F3F; Mon, 21 Jul 2003 23:42:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfi7s.dialup.mindspring.com ([165.247.200.252] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19eqqv-0001CB-00; Mon, 21 Jul 2003 23:42:26 -0700 Message-ID: <3F1CDC8A.D20F65F@mindspring.com> Date: Mon, 21 Jul 2003 23:41:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <20030721220459.37E8E2A8B2@canning.wemm.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b23258177d8a6ff625249ae79a1c4ad2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Mark Murray cc: current@freebsd.org cc: i386@freebsd.org Subject: Re: [-CURRENT tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 06:42:32 -0000 Dag-Erling Sm=F8rgrav wrote: > Peter Wemm 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