使用core dump调试Linux下程序的出错点

之前研究gmsv 发现gmsv每次关闭都会提示一个signal xx 之后仔细研究发现signal是个无比强大的东西 自从cg-x-server引用这个系统后 排错调试的效率大大提高了!哈哈哈…

采用网上已有文章的话说 就是

软中断信号（signal，又简称为信号）用来通知进程发生了异步事件。进程之间可以互相通过系统调用kill发送软中断信号。内核也可以因为内部事件而给进程发送信号，通知进程发生了某个事件。注意，信号只是用来通知某进程发生了什么事件，并不给该进程传递任何数据。

收到信号的进程对各种信号有不同的处理方法。处理方法可以分为三类：第一种是类似中断的处理程序，对于需要处理的信号，进程可以指定处理函数，由该函数来处理。第二种方法是，忽略某个信号，对该信号不做任何处理，就象未发生过一样。第三种方法是，对该信号的处理保留系统的默认值，这种缺省操作，对大部分的信号的缺省操作是使得进程终止。进程通过系统调用signal来指定进程对某个信号的处理行为。

在进程表的表项中有一个软中断信号域，该域中每一位对应一个信号，当有信号发送给进程时，对应位置位。由此可以看出，进程对不同的信号可以同时保留，但对于同一个信号，进程并不知道在处理之前来过多少个。

当程序收到SIGQU99v,SIGILL,SIGABRT,SIGFPE,SIGSEGV时候,linux会默认生成一个dump core,这个dump core可以通过gdb来查找程序崩溃的代码

使用流程如下
1.在编译的时候给CFLAG加入-g
2.使用ulimit -c unlimited设置系统保存dump core文件
3.程序崩溃后 会在当前目录生成一个core.pid的文件
4.使用gdb ./program core.pid 来进行检查
5.在gdb中用back track(bt)来查看出错信息

例

test.c

void a()
{
   char *p = NULL;
   printf("%d\n", *p);
}
int main()
{
    a();
    return 0;
}

shell
# gcc -g -o test test.c
# ./test
segmentation fault(core dump)
# gdb ./test core.2044
# tb
#0 0×08048373 in a () at test.c:4
#1 0×08048359 in main () at test.c:8

既可知道程序test.c 第四行出错 查找修复既可