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.
Created attachment 103016 [details] sigtest.c Here is the sigtest.c test program.
This problem is still present in the just-released 2.6.9-1.3_FC2 kernel.
This problem is still present in the just-released 2.6.9-1.6_FC2 kernel.
mass update for old bugs: Is this still a problem with the 2.6.9 based update kernel ?
As per comment #2 and comment #3, yes, this is still a problem with the most recent kernels available for Fedora Core 2.
I have just tested with kernel-2.6.9-1.11_FC2 (i686 version), the latest 2.6.9 update kernel for FC2 (just released recently) and this problem is still present.
I have just testing with kernel-2.6.10-1.8_FC2 (i686 version), the just-released 2.6.10 update kernel for FC2, and this problem is still present.
Although I feel like a squeaky wheel here, I must once again report that I have just tested with the recently released update kernel, kernel-2.6.10-1.12_FC2, and this problem is still present.
Just to keep this up to date, the recently released update kernel-2.6.10-1.14_FC2 RPM does not fix this problem.
The recently released kernel-2.6.10-1.770_FC2 still has this problem.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.