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