How to debug program with signal handler for SIGSEGV

Question

I am writing a plugin for a application, occasionally a SIGSEGV would be throw out. However, the application catches the signal SIGSEGV. In other word, The plugin is a dynamical library. The error occurs in my plugin and dynamical library. But the applcation handle the sSIGSEGV and exit normally. So, it is quite difficult for me to debug and get the backtrace of all stack frames. Any idea?

Currently I am using gdb as debug tool.

Answer 1

Even if the program traps SIGSEGV, gdb should still get it first and give you an opportunity to debug the program. Have you done something like

 handle SIGSEGV nostop

in GDB? If so that could be why it is not stopping.

Are you sure that a segfault is actually occurring? Can you duplicate this behavior with another program, or by intentionally causing a segmentation violation?

For example:

$ cat sig.c
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

void handle(int n)
{
        puts("Bail");
        exit(1);
}

int main()
{
        signal(SIGSEGV, handle);
        int *pi = 0;
        *pi = 10;
        return 0;
}
$ gcc -g sig.c
$ ./a.out
Bail
$ gdb ./a.out
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /home/elcapaldo/a.out

Program received signal SIGSEGV, Segmentation fault.
0x08048421 in main () at sig.c:15
15              *pi = 10;
(gdb) where
#0  0x08048421 in main () at sig.c:15
(gdb) c
Continuing.
Bail

Program exited with code 01.
(gdb) q

Answer 2

GDB will catch SIGSEGV before the application does.

What you described in comment to Logan's answer makes no sense.

I suspect what's really happening is that the application creates a new process, and only gets SIGSEGV in that other process, not the one you attached GDB to.

The following commands may be useful if my guess is correct:

(gdb) catch fork
(gdb) catch vfork
(gdb) set follow-fork-mode child

You might also want to edit and expand your question:

• how do you know there is a SIGSEGV to begin with?
• Posting a log of your interaction with GDB may also prove useful.