klibc - Mar 2005 - signal handlers segfault on Fedora kernels

Signal handlers in a klibc compiled program are not working with
Fedora-Devel shipped kernels. Therefore a klibc udev does simply
nothing on that boxes.

This simple program segfaults if Ctrl-C is pressed. The same compiled
with glibc works as expected. Any idea what the reason for that may be?

Thanks,
Kay


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>

__attribute__((__cdecl__)) static void sig_handler(int signum)
{
        return;
}

int main(int argc, char *argv[], char *envp[])
{
        struct sigaction act;

        memset(&act, 0x00, sizeof(struct sigaction));
        act.sa_handler = (void (*) (int))sig_handler;
        sigemptyset(&act.sa_mask);
        act.sa_flags = SA_RESTART;
        sigaction(SIGINT, &act, NULL);
        sigaction(SIGTERM, &act, NULL);

        sleep(100);
}

Kay Sievers wrote:
> Signal handlers in a klibc compiled program are not working with
> Fedora-Devel shipped kernels. Therefore a klibc udev does simply
> nothing on that boxes.
> 
> This simple program segfaults if Ctrl-C is pressed. The same compiled
> with glibc works as expected. Any idea what the reason for that may be?
I traced it, and when it invokes the target function, the stack pointer 
is most definitely *NOT* pointing to a return address like it should; it 
points to a word 0x00000420.
> (gdb) x/45wx $esp
> 0xbffff178:     0x00000420      0x00000002      0x00000000      0x00000000
> 0xbffff188:     0x0000007b      0x0000007b      0x00000000      0x080480a0
> 0xbffff198:     0x10000000      0xbffff454      0x00006639      0x00000000
> 0xbffff1a8:     0xbffff468      0xfffffdfe      0x00000001      0x00000000
> 0xbffff1b8:     0x0804836f      0x00000073      0x00200206      0xbffff454
> 0xbffff1c8:     0x0000007b      0x00000000      0x00000000      0x00000000
> 0xbffff1d8:     0x00000000      0x00000000      0x00000000      0x00000000
> 0xbffff1e8:     0x00000000      0x00000000      0x00000000      0x00000000
> 0xbffff1f8:     0x00000000      0x00000000      0x00000000      0x00000000
> 0xbffff208:     0x00000000      0x00000000      0x00000000      0x00000000
> 0xbffff218:     0x00000000      0x00000000      0x00000000      0x00000000
> 0xbffff228:     0x00000000
This is not even close to sane (there are at least 6 words on the stack 
before anything that looks like an address), and I have absolutely no 
idea what they have done to the kernel or glibc to "accomplish"
this...

	-hpa