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/
