Date: Thu, 17 Jul 2003 18:35:17 -0700 From: David Schultz <das@FreeBSD.ORG> To: Dag-Erling Smorgrav <des@des.no> Cc: sparc64@FreeBSD.ORG Subject: Re: [-CURRENT tinderbox] failure on sparc64/sparc64 Message-ID: <20030718013517.GA50428@HAL9000.homeunix.com> In-Reply-To: <20030717083101.GA51198@des.no> References: <200307141153.h6EBrJKk045346@cueball.rtp.FreeBSD.org> <20030715175821.K34004@beagle.fokus.fraunhofer.de> <xzp65m3vfw1.fsf@dwp.des.no> <20030715185438.GB15674@dhcp01.pn.xcllnt.net> <xzpy8yzty2m.fsf@dwp.des.no> <20030715190456.GC15674@dhcp01.pn.xcllnt.net> <xzpn0ffts1c.fsf@dwp.des.no> <20030717095257.C30394@beagle.fokus.fraunhofer.de> <20030717083101.GA51198@des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 17, 2003, Dag-Erling Smorgrav wrote: > On Thu, Jul 17, 2003 at 09:58:10AM +0200, Harti Brandt wrote: > > I have no idea how a program can core in vfork(). Probably a vm problem? > > Most likely a KSE-related problem in vfork(). Try replacing vfork() with > fork() in make(1) and see if the problem goes away. Warning: build times > may increase significantly... I would guess that the problem doesn't occur in the vfork() call itself, but in the child process (gzip?), and there's a problem that causes the child to be incompletely divorced from the parent. Is there any trick to reproducing this problem? I just did a make universe on i386 and didn't see it, but maybe my sources are too old. It would be interesting to see if fork() fixes the problem. With the VM optimizations, vfork() is only about 20% faster than fork(), so build times shouldn't be significantly impacted.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030718013517.GA50428>