Mail Archives: cygwin-developers/1999/08/28/23:16:09
Vadim Egorov <egorovv AT 1c DOT ru> writes:
> Hello,
>
> There is a problem with setjmp/longjmp/signals/exceptions that can be
> demonstrated by the following code:
>
> static jmp_buf env;
> static sigset_t set = {0};
>
> static void sig_handler(int sig)
> {
> sigprocmask(SIG_UNBLOCK, &set, 0);
> longjmp(env, sig);
> }
>
> int main(int argc, char * * argv)
> {
> sigaddset(&set, SIGSEGV);
>
> for ( int i = 0 ; i < 2; i++)
> {
> if ( setjmp(env) == 0 )
> {
> signal(SIGSEGV, ssig_handler);
> printf("exception ...");
> *(int*)0 = 1;
> }
> else
> {
> printf("trapped\n");
> }
> }
> return 0;
>
> }
>
> It traps exception only once and than hangs. The problem seems to be in
> longjmp code.
Interesting. It works every so often, and hangs the other times. strace
output shows that the signal is not being unblocked correctly, probably
due to the signal state not being restored correctly.
Almost the same behaviour I had writter earlier regarding FP exceptions.
I haven't tried your example under newer snapshots, so hopefully someone
else will try it out.
> If I load CRTDLL.DLL dynamically and use setjmp/longjmp from
> there all works. I traced MS longjmp and noticed that it calls RtlUnwind
> which seems do the trick.
This is of course dangerous since you're mixing runtimes, and anything
can happen. MSVCRT and CRTDLL provides two different setjmp/longjmp
pairs -- one "normal" that unwinds the stack to handle structure exceptions
and other with "ex" (you need to include setjmpex.h) that does not.
> In addition this code works on Linux without signal unblocking - it is
> necessary only if SIGSEGV is signaled by raise.
I have to go review the POSIX docs on this. I remember the issue of
undefined behaviour if SEGV, FPE, etc are ignored if not raised by
software exception via raise() or kill(). But your code as far as I
know is conforming and should work on POSIX systems.
Regards,
Mumit
- Raw text -