Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 11 Oct 2004 22:38:30 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: setjmp/longjmp & signal handlers bug
Message-ID: <20041012023830.GF17461@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT CYG DOT 4 DOT 58 DOT 0410111754160 DOT 1048 AT fordpc DOT vss DOT fsi DOT com> <20041011235128 DOT GD17461 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 58 DOT 0410112048460 DOT 15435 AT thing1-200>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.58.0410112048460.15435@thing1-200>
User-Agent: Mutt/1.4.1i

On Mon, Oct 11, 2004 at 08:56:52PM -0500, Brian Ford wrote:
>On Mon, 11 Oct 2004, Christopher Faylor wrote:
>>On Mon, Oct 11, 2004 at 06:00:07PM -0500, Brian Ford wrote:
>>>I would expect additional output:
>>>Partial success: 1
>>>PASS
>>>
>>>and a 0 return status?
>>
>>Did you try this on linux?
>
>No, Solaris 2.8 ;-).  Ok..., just tried Red Hat 8.0 kernel 2.4.18-27 and
>got my expected result there as well.

Ok, I just tried it on RH9 and see different results myself.

On linux 2.6.7 and 2.6.8.1 with glibc-2.3.3-30 it performs similarly to
cygwin and, in fact, performs as I'd expect it to.

>> The SEGV signal is blocked while it's in the signal handler so if you
>> jump out of the signal handler, it's still blocked.
>
>Huh?  It should be set to SIG_DFL, but not blocked.  Or, do you mean
>Cygwin subscribes to this non-standard out?

>If the handler is set to a function, then first either the handler is
>reset to SIG_DFL, or an implementation dependent blocking of the signal
>is performed, and next the handler is called...
>
>That's Cygwin's implementation dependent blocking?

Both cygwin and newer versions of linux, apparently.

>Can I just unblock it before calling signal again then?

Yes.  Have you tried it?

Either clear the blocking with sigprocmask or use sigsetjmp and siglongjmp.

>I expected the signal call on the next loop itteration to reset it back
>from SIG_DFL.  This is somewhat common code.  I was trying to resurect
>ElectricFence, and this is part of its test program.  Also, I'd bet it was
>the problem described here too:
>
>http://cygiwn.com/ml/cygiwn/2004-02/msg00948.html.

This has nothing to do with that.  This isn't new behavior.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/