*BSD News Article 33144


Return to BSD News archive

Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!paladin.american.edu!constellation!rex!ben
From: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
Subject: Re: gcc dies on signal 10 and 11 on kernel compile
Message-ID: <CtEMq9.3Cq@rex.uokhsc.edu>
Date: Sat, 23 Jul 1994 17:46:57 GMT
Reply-To: benjamin-goldsteen@uokhsc.edu
References: <Ct55AA.MzJ@usenet.ucs.indiana.edu> <Ct5Bou.Cx0@tfs.com> <1994Jul19.080403.28087@physiol.su.OZ.AU>
Organization: Health Sciences Center, University of Oklahoma
Lines: 65

john@physiol.su.OZ.AU (John Mackin) writes:

>In article <Ct5Bou.Cx0@tfs.com> julian@tfs.com (Julian Elischer) writes:

>> In article <Ct55AA.MzJ@usenet.ucs.indiana.edu>,
>>	Jim Pitts <pitts@mimosa.astro.indiana.edu> wrote:

>>> Everything went fine with the install.  It wasn't until I tried to recompile
>>> the kernel that I had my first problem.  The compiler kept halting on a
>>> signal 10 or a signal 11.

>> If it makes you feel any better, ref.tfs.com also suffers from this
>> problem. I haven't spent a LOT of time trying to track it down,
>> but there is something screwed in the VM system that is triggered by some
>> hardware configurations or something.

>Yes, that's definitely correct.  I had this when I first put a FreeBSD
>machine together.  I wonder: do either of the machines exhibiting
>the problem have much memory/swap?  The configuration I got this
>problem on was 4Mb RAM and 4 Mb of swap.  I knew it was something
>screwy with the kernel, since the signals weren't repeatable:
>you could restart the make and it would continue.  I'd see either
>signal 11 in gcpp or gcc1, signal 10 in gcc1 or signal 11 in make
>itself, or signal 6 (abort) in gcc1.

I had these exact same errors!

>I assumed the problem was due to exhaustion of some resource, since
>the make would always run for ten or fifteen files before dying.

Almost the same.  Usually it would run for 10-15 files, but then it
might run for less files and then maybe it wouldn't complete a compile
unless I rebooted.

One thing that worked under FreeBSD (but not under Linux) was to run a
processes that allocated all the memory it could and then test it.  The
memory tester program never found the problem but the problem went away
for a while after the tester program was killed.

>I also noticed that the top-level make, the one that was controlling
>the build and hence not exiting (until it died), was actually
>growing while the build was going on: something I was rather
>surprised to see, and that made me wonder if the machine was
>just plain running out of VM.  I could well believe that the
>programs wouldn't check properly for success of memory allocation.
>I didn't investigate it further since I had other hardware problems
>at that stage, due to a flaky NPX.

I removed my fifth MB of memory (my first 4 MB were 70ns SIMMS with
parity that I bought a year ago; the fifth MB of memory was the
original 1 MB of 80ns DIP chips) and now my FreeBSD systems works fine
(by the way, I also had this problem under Linux and NetBSD 0.9).

>On my current configuration, with a different motherboard, 8 Mb RAM
>and 8 Mb swap, it doesn't die.

Since I only had 4/5 MB of RAM, I had 8-12 MB of swap.  That wasn't the
problem for me.

>-- 
>John Mackin <john@physiol.su.oz.au>
>Knox's box is a 286.                 Fox in Socks does hacks and tricks
>Knox's box is hard to fix.           To fix poor Knox's box for kicks.
-- 
Benjamin Z. Goldsteen