This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setjmp/longjmp & signal handlers bug

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
>>>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 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:

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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]