From owner-freebsd-hackers Thu Feb 20 3: 9:58 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF09D37B405 for ; Thu, 20 Feb 2003 03:09:56 -0800 (PST) Received: from subway.linast.de (linast.blasberg-computer.de [62.67.45.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BDA443F75 for ; Thu, 20 Feb 2003 03:09:55 -0800 (PST) (envelope-from sl@linast.de) Received: from scrap (p508567CF.dip0.t-ipconnect.de [80.133.103.207]) (authenticated bits=0) by subway.linast.de (8.12.6/8.12.6) with ESMTP id h1KB9lD4060832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 20 Feb 2003 12:09:50 +0100 (CET) (envelope-from sl@linast.de) Date: Thu, 20 Feb 2003 12:10:27 +0100 From: Sebastian Lederer To: Wes Peters Cc: V.Haisman@sh.cvut.cz, freebsd-hackers@freebsd.org Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop Message-Id: <20030220121027.31d74d3f.sl@linast.de> In-Reply-To: <200302190851.23498.wes@softweyr.com> References: <20030219134131.T70370-100000@logout.sh.cvut.cz> <200302190851.23498.wes@softweyr.com> Organization: Linast-Systemtechnik GmbH X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-unknown-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Feb 2003 08:51:23 -0800 Wes Peters wrote: > On Wednesday 19 February 2003 04:43, Vaclav Haisman wrote: [...] > > Besides, this doesn't explain anything. I see I haven't asked any > > question in my previous post. So, why does FreeBSD behave different? > > Because it *is* different? If you want to catch a signal and be > able to handle it, the other two are wrong, are they not? > [...] I think the real question here is, what happens if a SIGSEGV occurs when SIGSEGV is already blocked (like inside the handler)? See the simple test program below. It seems that on FreeBSD, the process just loops on the faulting instruction, whereas Linux and Solaris kill the process, producing a SIGSEGV exit code. I don't know what the correct behaviour is. It is possible to recover from such a SIGSEGV loop from inside the process, using a timer signal, for example, so you might say it is legal to do this and FreeBSD has the correct behaviour. On the other hand, it's most likely just a badly coded crashed program that would waste all free CPU cycles if not killed right away. - Sebastian Lederer --- #include #include void crash() { int *p=NULL; *p=0xdead; } int main(int argc, char **argv) { sigset_t set; sigset_t oset; sigemptyset(&set); sigaddset(&set,SIGSEGV); sigprocmask(SIG_SETMASK,&set,&oset); crash(); sigprocmask(SIG_SETMASK,&oset,NULL); return 0; } --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message