From owner-freebsd-stable  Mon Jan  8 14: 5: 7 2001
Delivered-To: freebsd-stable@freebsd.org
Received: from saturn.home.ben.com (c1058885-a.bvrtn1.or.home.com [24.12.186.106])
	by hub.freebsd.org (Postfix) with ESMTP id A3E3237B7F2
	for <freebsd-stable@FreeBSD.ORG>; Mon,  8 Jan 2001 13:32:46 -0800 (PST)
Received: (from bjj@localhost)
	by saturn.home.ben.com (8.11.1/8.9.3) id f08LWhL18526;
	Mon, 8 Jan 2001 13:32:43 -0800 (PST)
From: Ben Jackson <ben@ben.com>
Message-Id: <200101082132.f08LWhL18526@saturn.home.ben.com>
Subject: Re: SIGSEGV can be blocked!?
In-Reply-To: <20010108161854.A3547@mezcal.tue.le> from Thomas Zenker at "Jan
 8, 2001 04:18:55 pm"
To: Thomas Zenker <thz@Lennartz-electronic.de>
Date: Mon, 8 Jan 2001 13:32:43 -0800 (PST)
Cc: freebsd-stable@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Blocking SIGSEGV with sigprocmask does really BLOCK it. 
> I think, this is a bug. I discovered this because I wanted to
> provoke a core dump by a write to (int *)0, but the process got hung,

The instruction that caused the SEGV is going to restart after any handler
runs because the handler may have mapped the page that caused the fault.

On other operating systems you can block SEGV for purposes of asynchronous
signals (ie `kill -SEGV') but not for synchronous signals.  To quote from
the Solaris sigprocmask manpage:

     Signals that  are  generated  synchronously  should  not  be
     masked.  If  such  a  signal  is  blocked and delivered, the
     receiving process is killed.

and indeed a test program shows that you still get SEGV in that case.
You can still shoot yourself in the foot with a SEGV handler that doesn't
eliminate the fault.

--Ben


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message