[PATCH] Fix signull test case

[PATCH] Fix signull test case

[Ulrich Weigand]

Hello,

the signull.exp test case fails when running under a 2.6 kernel,
because it uses longjmp to leave a SIGSEGV handler.  This results
in the signal remaining blocked for the rest of program execution,
and the second segmentation violation triggered by the test case
simply terminates the program.  The fix is to use siglongjmp.

Also, the test case uses 'signal' to install the signal handler;
according to POSIX it is undefined whether this routine installs
the handler with the 'one-shot' property or not.  (Apparently,
on BSD-like systems 'one-shot' is the default.)

Thus, I've also changed the test case to use sigaction instead,
to make sure the handler remains active across multiple invocations.
(This isn't currently an actual problem on Linux systems -- if you
prefer I can remove this part.)

Tested on s390-ibm-linux and s390x-ibm-linux, fixes one test suite
failure.

OK?


ChangeLog:

	* gdb.bas/signull.c: Use sigsetjmp/siglongjmp instead of 
	setjmp/longjmp.  Use sigaction instead of signal.

Index: gdb/testsuite/gdb.base/signull.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/signull.c,v
retrieving revision 1.1
diff -c -p -r1.1 signull.c
*** gdb/testsuite/gdb.base/signull.c	13 May 2004 18:12:07 -0000	1.1
--- gdb/testsuite/gdb.base/signull.c	20 May 2004 13:10:52 -0000
***************
*** 19,24 ****
--- 19,25 ----
  
  #include <signal.h>
  #include <setjmp.h>
+ #include <stdlib.h>
  
  enum tests {
    code_entry_point, code_descriptor, data_pointer
*************** jmp_buf env;
*** 38,44 ****
  extern void
  keeper (int sig)
  {
!   longjmp (env, 0);
  }
  
  extern long
--- 39,45 ----
  extern void
  keeper (int sig)
  {
!   siglongjmp (env, 0);
  }
  
  extern long
*************** int
*** 59,68 ****
  main ()
  {
    static volatile int i;
!   signal (SIGSEGV, keeper);
    for (i = 0; i < 10; i++)
      {
!       setjmp (env);
        bowler ();
      }
  }
--- 60,74 ----
  main ()
  {
    static volatile int i;
! 
!   struct sigaction act;
!   memset (&act, 0, sizeof act);
!   act.sa_handler = keeper;
!   sigaction (SIGSEGV, &act, NULL);
! 
    for (i = 0; i < 10; i++)
      {
!       sigsetjmp (env, 1);
        bowler ();
      }
  }
-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: [PATCH] Fix signull test case

[Daniel Jacobowitz]

On Thu, May 20, 2004 at 03:30:51PM +0200, Ulrich Weigand wrote:
> Hello,
> 
> the signull.exp test case fails when running under a 2.6 kernel,
> because it uses longjmp to leave a SIGSEGV handler.  This results
> in the signal remaining blocked for the rest of program execution,
> and the second segmentation violation triggered by the test case
> simply terminates the program.  The fix is to use siglongjmp.
> 
> Also, the test case uses 'signal' to install the signal handler;
> according to POSIX it is undefined whether this routine installs
> the handler with the 'one-shot' property or not.  (Apparently,
> on BSD-like systems 'one-shot' is the default.)
> 
> Thus, I've also changed the test case to use sigaction instead,
> to make sure the handler remains active across multiple invocations.
> (This isn't currently an actual problem on Linux systems -- if you
> prefer I can remove this part.)
> 
> Tested on s390-ibm-linux and s390x-ibm-linux, fixes one test suite
> failure.
> 
> OK?

There's a typo in your changelog entry: gdb.bas/.  Otherwise this is OK
- thank you very much!  Fixes two failures on i386-pc-linux-gnu.

-- 
Daniel Jacobowitz

Re: [PATCH] Fix signull test case

[Andrew Cagney]

Hello,

the signull.exp test case fails when running under a 2.6 kernel,
because it uses longjmp to leave a SIGSEGV handler.  This results
in the signal remaining blocked for the rest of program execution,
and the second segmentation violation triggered by the test case
simply terminates the program.  The fix is to use siglongjmp.
Hmm, checking POSIX, it was left unspecified.  I choose to read the 
wrong man page :-(

Also, the test case uses 'signal' to install the signal handler;
according to POSIX it is undefined whether this routine installs
the handler with the 'one-shot' property or not.  (Apparently,
on BSD-like systems 'one-shot' is the default.)
Very very old systems.  Modern BSD systems leave the signal in place.

Thus, I've also changed the test case to use sigaction instead,
to make sure the handler remains active across multiple invocations.
(This isn't currently an actual problem on Linux systems -- if you
prefer I can remove this part.)
Tested on s390-ibm-linux and s390x-ibm-linux, fixes one test suite
failure.
Andrew