Bug 130743

Description of problem:

 Programs that set up signal handlers without setting SA_RESTORER
segfault when they attempt to return from system calls when run
on kernel 2.6.8-1.521 (on an i686 machine). This problem is not
seen on 2.6.7-1.494.2.2 or on stock 2.6.8.1.

 Because glibc normally forces a SA_RESTORER down your throat,
the easiest way to see this problem is to be using a program
compiled with an alternate, more minimal libc such as dietlibc.

 This problem first manifested when my shell, linked against
dietlibc, suddenly started coredumping when I hit ^C to interrupt
something it was running when we upgraded to 2.6.8-1.521.

Version-Release number of selected component (if applicable):

 kernel-2.6.8-1.521 on an i686 uniprocessor.
 dietlibc-0.24-4

How reproducible:

 Always.

Steps to Reproduce:
1. # yum install dietlibc
(Or use your favorite method of installing dietlibc; it's a stock
 Fedora Core 2 RPM.)

2. Save a copy of the program in the attachment as 'sigtest.c'.

3. Compile: diet gcc -g -o sigtest sigtest.c

4. Run: ./sigtest
   Hit ^C once it prints '<pid> ready:' and it will coredump
   after printing signal handler information.
   Run './sigtest -r' to make it supply its own SA_RESTORER
   and repeat, and it won't coredump.
  
Actual results:

 A signal handler printout and then a segfault.

Expected results:

 A signal handler printout and no segfault and the program
keeps on running.

Additional info:

 Since sigtest prints out the return address the signal handler
will be returning to (via __builtin_return_address), it's easy
to see how busted things are; I see things like 'returning to
0x00000420', which is clearly unlikely to work.

 If you compile and link against normal glibc, you can strace
the program to see that glibc always forces use of its own
SA_RESTORER handler no matter what.