Why can't I ignore SIGSEGV signal?

15,823

Solution 1

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 11
100

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.

Solution 2

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 the next run

Solution 3

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.

Solution 4

Trying to ignore or handle a SIGSEGV is the wrong approach. A SIGSEGV triggered by your program always indicates a bug. Either in your code or code you delegate to. Once you have a bug triggered, anything could happen. There is no reasonable "clean-up" or fix action the signal handler can perform, because it can not know where the signal was triggered or what action to perform. The best you can do is to let the program fail fast, so a programmer will have a chance to debug it when it is still in the immediate failure state, rather than have it (probably) fail later when the cause of the failure has been obscured. And you can cause the program to fail fast by not trying to ignore or handle the signal.

Share:
15,823

Related videos on Youtube

Dinesh
Author by

Dinesh

The more I learn, the more I realize how much I don't know. #SOreadytohelp

Updated on June 04, 2022

Comments

  • Dinesh
    Dinesh almost 2 years

    Here is my code,

    #include<signal.h>
    #include<stdio.h>
    
    int main(int argc,char ** argv)
       {
         char *p=NULL;
         signal(SIGSEGV,SIG_IGN); //Ignoring the Signal
         printf("%d",*p);
         printf("Stack Overflow"); //This has to be printed. Right?
       return 0;
        }
    

    While executing the code, i'm getting segmentation fault. I ignored the signal using SIG_IGN. So I shouldn't get Segmentation fault. Right? Then, the printf() statement after printing '*p' value must executed too. Right?

    • 6502
      6502 over 12 years
      There will be a time in which writing code that swallows segfaults will be be considered enough to put the programmer in jail.
  • Dinesh
    Dinesh over 12 years
    Ok, So what do I have to do exactly?
  • ibid
    ibid over 12 years
    @Dinesh, what is it that you are trying to accomplish?
  • Dinesh
    Dinesh over 12 years
    @ibid, In code, I'm trying to access a memory null memory. SO it leads to creation of SIGSEGV signal. But I made a handler for that which will just print "Catching the signal". Afterwards the statement "return 0" which resides in main() must execute. Right?
  • cnicutar
    cnicutar over 12 years
    @Dinesh Currently the code you're posting simply ignores the signal, it doesn't establish a signal handler (sighandler) for it. Even if that were the case, I suspect it would continuously print "catching signal".
  • Dinesh
    Dinesh over 12 years
    @cnicutar, Oh, Then can you tell me how to add sighandler for that? Can you give me any link where I can get to know about that
  • cnicutar
    cnicutar over 12 years
    @Dinesh Just set sighandler as the handler. But for the fixing part, there's no general way to fix a segfault. Just a few mmap tricks.
  • Dinesh
    Dinesh over 12 years
    Thanks for your detailed explanation Adam :)
  • mortenpi
    mortenpi almost 7 years
    As far as I can tell this doesn't work if you run into the segfault multiple times (the second time the process still segfaults). AFAIU longjmp/setjmp doesn't handle the signal context properly, and sigsetjmp/siglongjmp should be used instead. Cf "Notes" in linux.die.net/man/2/setcontext
  • Peter Cordes
    Peter Cordes almost 5 years
    It's not always a bug. Some JVMs or Javascript engines will sometimes put the end of an array at the end of a page that's followed by an unmapped page, offloading bounds checking to the hardware. SIGSEGV means the guest Java or Javascript code took an array out-of-bounds exception, not that the JVM itself is buggy. But yes, outside of planned cases like this, it's a bug and should not be ignored.
  • Bogatyr
    Bogatyr about 3 years
    Programs can also specifically mprotect() a range of memory and use a SIGSEGV handler to know that an address within the range was accessed.
  • Bogatyr
    Bogatyr about 3 years
    My question is why doesn't the program just go into an infinite loop? Is SIGSEGV special, in that ignoring it is the same as setting the default action (kill process and do a core dump)?