From owner-freebsd-current Wed Mar 26 11:15:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA11504 for current-outgoing; Wed, 26 Mar 1997 11:15:24 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA11487 for ; Wed, 26 Mar 1997 11:15:17 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id LAA14966; Wed, 26 Mar 1997 11:13:53 -0800 (PST) To: Terry Lambert cc: drussell@saturn-tech.com, freebsd-current@freebsd.org Subject: Re: SIGTERMs killing X In-reply-to: Your message of "Wed, 26 Mar 1997 11:27:01 MST." <199703261827.LAA28346@phaeton.artisoft.com> Date: Wed, 26 Mar 1997 11:13:53 -0800 Message-ID: <14962.859403633@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hmmm... perhaps. So are you going to change the comment so that > it implies what you said instead of implying what I said? Well, it's not even my comment, so I'm not apt to fool with it. :) FWIW, I didn't read it that way - I see it as just one of the ways in which execve() can fail and someone's attempt to pass back a little extra info about it by [ab]using the signal flags. It would be interesting to check whether any applications are actually using this to provide extra information about a failure. I know that it's not documented in the man page. :-) > PS: I'd be interested to see *anywhere* else in the kernel where the > SIGABRT signal is sent. I've grepped the sources, and the only place There aren't any other places, from what I can tell. Again, the problem you were responding to was almost certainly an internal application abort() and the VM overcommit issue you raised would have raised a KILL and logged it on the system console if that had been the culprit here. Jordan