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 18.104.22.168.
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.
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.
A signal handler printout and then a segfault.
A signal handler printout and no segfault and the program
keeps on running.
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]
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
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.