This is the mail archive of the cygwin-developers@sourceware.cygnus.com 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]

Re: longjmp problem


Vadim Egorov <egorovv@1c.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


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