This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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
>>>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/