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


On Fri, Aug 27, 1999 at 01:40:03PM +0400, Vadim Egorov wrote:
>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.  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.  In addition this
>code works on Linux without signal unblocking - it is necessary only if
>SIGSEGV is signaled by raise.

It should be pretty easy to run this in a debugger and see where it's
hanging or attach to a hung process and get a stack trace from a couple
of the threads.

I would like to encourage people to do this.  It could help DJ or me
figure out where the problem lies without having to duplicate somebody
else's effort.

In this case, I suspect that setjmp itself is being interrupted so env
is in an unknown state when the the signal handler uses it.

-chris

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