Why can't I ignore SIGSEGV signal?

Your code is ignoring SIGSEGV instead of catching it. Recall that the instruction that triggered the signal is restarted after handling the signal. In your case, handling the signal didn't change anything so the next time round the offending instruction is tried, it fails the same way.

If you intend to catch the signal change this

signal(SIGSEGV, SIG_IGN);

to this

signal(SIGSEGV, sighandler);

You should probably also use sigaction() instead of signal(). See relevant man pages.

In your case the offending instruction is the one which tries to dereference the NULL pointer.

printf("%d", *p);

What follows is entirely dependent on your platform.

You can use gdb to establish what particular assembly instruction triggers the signal. If your platform is anything like mine, you'll find the instruction is

movl    (%rax), %esi

with rax register holding value 0, i.e. NULL. One (non-portable!) way to fix this in your signal handler is to use the third argument signal your handler gets, i.e. the user context. Here is an example:

#include <signal.h>#include <stdio.h>#define __USE_GNU#include <ucontext.h>int *p = NULL;int n = 100;void sighandler(int signo, siginfo_t *si, ucontext_t* context){  printf("Handler executed for signal %d\n", signo);  context->uc_mcontext.gregs[REG_RAX] = &n;}int main(int argc,char ** argv){  signal(SIGSEGV, sighandler);  printf("%d\n", *p); // ... movl (%rax), %esi ...  return 0;}

This program displays:

Handler executed for signal 11100

It first causes the handler to be executed by attempting to dereference a NULL address. Then the handler fixes the issue by setting rax to the address of variable n. Once the handler returns the system retries the offending instruction and this time succeeds. printf() receives 100 as its second argument.

I strongly recommend against using such non-portable solutions in your programs, though.

You can ignore the signal but you have to do something about it. I believe what you are doing in the code posted (ignoring SIGSEGV via SIG_IGN) won't work at all for reasons which will become obvious after reading the bold bullet.

When you do something that causes the kernel to send you a SIGSEGV:

• If you don't have a signal handler, the kernel kills the process and that's that
• If you do have a signal handler
  • Your handler gets called
  • The kernel restarts the offending operation

So if you don't do anything abut it, it will just loop continuously. If you do catch SIGSEGV and you don't exit, thereby interfering with the normal flow, you must:

• fix things such that the offending operation doesn't restart or
• fix the memory layout such that what was offending will be ok on thenext run

Another option is to bracket the risky operation with setjmp/longjmp, i.e.

#include <setjmp.h>#include <signal.h>static jmp_buf jbuf;static void catch_segv(){    longjmp(jbuf, 1);}int main(){    int *p = NULL;    signal(SIGSEGV, catch_segv);    if (setjmp(jbuf) == 0) {        printf("%d\n", *p);    } else {        printf("Ouch! I crashed!\n");    }    return 0;}

The setjmp/longjmp pattern here is similar to a try/catch block. It's very risky though, and won't save you if your risky function overruns the stack, or allocates resources but crashes before they're freed. Better to check your pointers and not indirect through bad ones.