This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: setjmp/longjmp & signal handlers bug
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.
> You get roughly the same behavior.
Uh..., nope.
> 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 blcoking? Can I just unblock it
before calling signal again then?
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.
Please clarify your reasoning. Thanks.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...
--
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/