Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!physiol.su.OZ.AU!john From: john@physiol.su.OZ.AU (John Mackin) Subject: Re: gcc dies on signal 10 and 11 on kernel compile Message-ID: <1994Jul19.080403.28087@physiol.su.OZ.AU> Organization: The Land of Summer's Twilight References: <Ct55AA.MzJ@usenet.ucs.indiana.edu> <Ct5Bou.Cx0@tfs.com> Date: Tue, 19 Jul 1994 08:04:03 GMT Lines: 41 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 assumed the problem was due to exhaustion of some resource, since the make would always run for ten or fifteen files before dying. 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. On my current configuration, with a different motherboard, 8 Mb RAM and 8 Mb swap, it doesn't die. -- 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.