Date: Tue, 25 Mar 1997 21:50:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: drussell@saturn-tech.com (Doug Russell) Cc: freebsd-current@freebsd.org Subject: Re: SIGTERMs killing X Message-ID: <199703260450.VAA27126@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95.970325193822.22277B-100000@hobbes.saturn-tech.com> from "Doug Russell" at Mar 25, 97 07:46:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703260450.VAA27126>