From owner-freebsd-current Tue Mar 25 21:04:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA15124 for current-outgoing; Tue, 25 Mar 1997 21:04:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA15118 for ; Tue, 25 Mar 1997 21:04:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA27126; Tue, 25 Mar 1997 21:50:50 -0700 From: Terry Lambert Message-Id: <199703260450.VAA27126@phaeton.artisoft.com> Subject: Re: SIGTERMs killing X To: drussell@saturn-tech.com (Doug Russell) Date: Tue, 25 Mar 1997 21:50:50 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: from "Doug Russell" at Mar 25, 97 07:46:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > All this talk of signals reminds me of a (totally) unrelated problem one > of my machines seems to be having lately..... My main workstation, which > usually runs X all the time, has exited on a sig 6 from X a couple times > in the last few days for no apparent reason. > > Mar 24 12:22:23 586quick166 /kernel: pid 218 (XF86_SVGA), uid 0: exited on signal 6 > Mar 25 11:27:22 586quick166 /kernel: pid 7136 (XF86_SVGA), uid 0: exited on signal 6 > > I can't for the life of me determine why it would have got an ABORT > signal.... Where would that be coming from? The machine is just sitting > there idle (AFAIK, anyway... :)) and when I get home from work, for > example, it's no longer running X. It is because FreeBSD is overcommiting memory in it's VM system. I am sorry for you that you got this error... I am glad you got this error, because you are a real-world example of a need for a tunable which I have been lobbying for for four years. Now I have a sample case, and I am happy because I can flagellate the powers that be every time the topic comes up in the future. 8-). What it means is that your VM space for your process has been destroyed (you can see this by looking in /sys/kern/kern_exec.c). This can happen when you have run out of virtual memory, and you get a write fault on a copy-on-write page. When this happens, the page is supposed to be copied to another page and the process map adjusted to cause the write to accutually occur in a copy of the page instead of the actual page. This can similarly occur when you have a MAP_PRIVATE mmap()'ed file or a shared memory segment mapped and on which you have changed page protections (by default FreeBSD does not support mapping shared memory copy on write). If it can't get a page, then the fault can not be serviced, and your process can not continue running. To rememdy this, you should increas the amount of swap space you have. Note: it is possible that in the move to 3.0, the VM system was damaged such that it could not reclaim otherwise reclaimable pages (ie: a kernel memory leak). If you have a large amount of swap, you should consider determining if a leak is ocurreing, and report the problem to David Greenman or John Dyson, if you find that there is a leak, since adding swap in this case will only cause a longer delay before the onset of the problem. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.