This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: longjmp problem
- To: Vadim Egorov <egorovv@1c.ru>
- Subject: Re: longjmp problem
- From: Chris Faylor <cgf@cygnus.com>
- Date: Mon, 30 Aug 1999 11:38:50 -0400
- Cc: "cygwin-developers@sourceware.cygnus.com" <cygwin-developers@sourceware.cygnus.com>
- References: <37C65CF3.50E89A09@1c.ru>
- Reply-To: cygwin-developers@sourceware.cygnus.com
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