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

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


I ran into this very problem with a test program that I wrote for the shmdt
() call.
The test purposely has an assignment statement that will cause a SIGSEGV
to be generated.  Like you, I found that handling SIGSEGV is tricky.  After
with some other engineers, I choose to use the sigsetjmp() and siglongjmp()
in much the same way that you are using setjmp() and longjmp().  The former
allow saving of signal context, although my test is not making use of that
at this

The bottom line is that I believe the use of these calls is an acceptable
way to handle
SIGSEGV in an interal signal handling function.

Wayne Boyer
IBM - Beaverton, Oregon
(503) 578-5236
T/L 775-5236

Nathan Straz <nstraz@sgi.com>@oss.sgi.com on 03/01/2001 03:21:09 PM

Sent by:  owner-ltp@oss.sgi.com

To:   ltp@oss.sgi.com
Subject:  [LTP] New stat() test cases, please comment

Back in September we stumbled over the EFAULT/SIGSEGV dilemma that glibc
produced.  The short story is that the kernel returns EFAULT if it gets
a bad pointer, but glibc will send SIGSEGV if it gets a bad pointer
while doing syscall related work.  I think I may have found a workaround
that will at least help testing.

Signal handlers for SIGSEGV can't return to the code gracefully.  They
can however force their way back with a longjmp().  I add a new signal
handler before the expected segfault and call setjmp().  The signal
handler will catch SIGSEGV and throw us back to the setjmp() point where
we kindly follow the other path and report the error.

I've added code to do this to the new test program stat06.  Please take
a look at it and tell me if this is an acceptable hack.  I've created a
new tarball that includes the new test case.

Nate Straz                                              nstraz@sgi.com
sgi, inc                                           http://www.sgi.com/
Linux Test Project                    http://oss.sgi.com/projects/ltp/