[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
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
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.
IBM - Beaverton, Oregon
Nathan Straz <firstname.lastname@example.org>@oss.sgi.com on 03/01/2001 03:21:09 PM
Sent by: email@example.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 firstname.lastname@example.org
sgi, inc http://www.sgi.com/
Linux Test Project http://oss.sgi.com/projects/ltp/