[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LTP] New stat() test cases, please comment







Nathan Straz <nstraz@sgi.com>@maine.americas.sgi.com> on 03/07/2001
09:43:45 AM

> > will cause a SIGSEGV to be generated.  Like you, I found that handling
> > SIGSEGV is tricky.  After talking with some other engineers, I choose
> > to use the sigsetjmp() and siglongjmp() calls in much the same way
> > that you are using setjmp() and longjmp().  The former two allow
>
> Did they have any concerns.  This looks like an ugly hack to several
> people I've spoken to.  It seems to work, but I'm concerned that it
> won't always.
>

I discussed this a bit further and the conclusion was that sigsetjmp()
and siglongjmp() are more appropriate because they can save the signal
context as well.  The sigsetjmp man page says something about this
in the NOTES section.  There weren't any concerns that this could be
problematic.

The code snippet in my program now looks something like this:

if (sigsetjmp(env, 1) == 0) {
     *shared = 2;   /* this should generate our SIGSEGV */
}

.
.
.

void
sighandler(sig)
{
        /* if we have received a SIGSEGV, we are almost done */
        if (sig == SIGSEGV) {
                /* set the global variable and jump back */
                pass = 1;
                siglongjmp(env, 1);
        } else {
                tst_brkm(TBROK, cleanup, "received an unexpected signal");
        }
}


Wayne Boyer
IBM - Beaverton, Oregon
wboyer@us.ibm.com
(503) 578-5236
T/L 775-5236