Date: Tue, 25 Mar 1997 22:50:39 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: drussell@saturn-tech.com (Doug Russell), freebsd-current@freebsd.org Subject: Re: SIGTERMs killing X Message-ID: <2530.859359039@time.cdrom.com> In-Reply-To: Your message of "Tue, 25 Mar 1997 21:50:50 MST." <199703260450.VAA27126@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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... Ah, I just love it when Terry gleefully spies the football heading his way, runs to intercept it and makes one of those beautiful diving catches you only see on the NFL videos, catching it, spinning gracefully over one shoulder and coming to his feet again, all in a single motion, running away from a frustrated knot of offensive tackles to dance into the touchdown zone. Unfortunately, when he goes to spike the ball in victory, it turns out that his catch is not a football but an irate pigeon who pecks him solidly on the nose for his offense and flies away. Sigh, all that effort and style to no end! ;-) In this case, Terry's pigeon was SIGABRT, which is not the same as the SIGKILL which FreeBSD delivers to a process which has generated an out-of-VM condition. But for a mere delta of 3 in the signal number, Terry might have been correct. :-) As it is, he's entirely on the wrong track yet again. The SIGABRT must be something which is caught internally by the server, perhaps in response to a NULL pointer reference or malloc() returning zero (which could be bogus limit values just as easily as anything else). More than this without knowing more about the user's configuration, it's difficult to say. > 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). Erm, you can? :-) You're not looking at the exec_fail case by mistake, are you? Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2530.859359039>