[lkml]   [2003]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Never mind. Re: Signal left blocked after signal handler.

On Wed, 26 Nov 2003, Bruce Perens wrote:
> The test code works on 2.4, but the electric fence confidence test does
> not. Maybe something odd with SIGSEGV, which is
> what that confidence test is catching. I will go back and see why.

One difference in 2.4.x and 2.6.x is the signal blocking wrt blocked
signals that are _forced_ (ie anything that is thread-synchronous, like a
SIGSEGV/SIGTRAP/SIGBUS that happens as a result of a fault):

- in 2.4.x they will just punch through the block
- in 2.6.x they will refuse to punch through a blocked signal, but
since they can't be delivered they will cause the process to be

Trivial test program:

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

void sigsegv(int sig)
*(int *)0=0;

int main(int argc, char **argv)
struct sigaction sa = { .sa_handler = sigsegv };

sigaction(SIGSEGV, &sa, NULL);
*(int *)0 = 0;

and in 2.4.x this will cause infinte SIGSEGV's (well, they'll be caught by
the stack size eventually, but you see the problem: do a "strace" to see
what's going on). In 2.6.x the second SIGSEGV will just kill the program

If you _want_ the recursive behaviour, you should add

.sa_flags = SA_NODEFER

to the sigaction initializer.

I don't understand why your test-program works differently on 2.4.x,
though, since a "kill()" system call is _not_ thread-synchronous, and
should never punch through anything. Not even on 2.4.x.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.039 / U:9.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site