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, 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.

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

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

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