Linux signal捕获_使用signal获取死机

signal的原理这里不打算多讲，这里主要讲一下应用

man 7 signal，可以看到一些关于signal的介绍：

每个信号都对应着一个action，默认的有：Term, Ign,core,Stop,Cont,  文档上明确的写着是以进程为修改单位的，所有的线程的action都相同：

The signal disposition is a per-process attribute: in a multithreaded application, the disposition of a particular signal is the same for all threads.

信号对应的action被执行了才称之为这个signal被delivered，signal已经发出了，但是没有执行action，称之为signal被pending了，每个线程都可以单独设置mask，来block一些信号，当有对应的signal到来时，这些信号就被pending了，直到再次设置mask在unblock这些signal， pending的signal才会被执行。

signal和默认的action直接的对应关系为：

core就是产生core dump（需要kernel打开coredump选项支持，ulimit -c unlimited不限制core文件大小，core文件的路径可读写），因此可以看出并不是所有的死机都会产生core文件，测试coredump是否生效可以使用下面命令：

kill  -s 11   pid

linux有时会出现应用莫名奇妙的死机，死机毫无规律可循，这时就可以考虑捕获信号，如果了解过kernel的原理就会知道死机都是由信号引起的。

捕获信号的本质就是改变action，action其实就是一个函数指针，改变这个函数指针以指向自定义的函数，sigaction(2) or signal(2)都可以进行捕获，但是signal(2)缺乏移植性。

注意这些signal_handler()是在用户空间执行的，内核采用了Trampoline机制，感兴趣的可以查阅相关资料了解一下。

下面给出一个捕获的例子： 

#if DEBUG_SEGV_HANDLER
 
          struct sigaction sa;
          memset(&sa, 0, sizeof(sa));
          sa.sa_sigaction = handle_sigsegv;
          sa.sa_flags = SA_SIGINFO;
          sigaction(SIGSEGV, &sa, NULL);
          sigaction(SIGILL, &sa, NULL);
          sigaction(SIGFPE, &sa, NULL);
          sigaction(SIGBUS, &sa, NULL);
 
#endif
 
  #if DEBUG_SEGV_HANDLER
  static
  void handle_sigsegv(int sig, siginfo_t *info, void *ucontext)
  {
      long ip;
      ucontext_t *uc;
  
      uc = ucontext;
      ip = uc->uc_mcontext.gregs[REG_EIP];
      fdprintf(2, "signal:%d address:0x%lx ip:0x%lx\n",
              sig,
              /* this is void*, but using %p would print "(null)"
               * even for ptrs which are not exactly 0, but, say, 0x123:
               */
              (long)info->si_addr,
              ip);
      {
          /* glibc extension */
          void *array[50];
          int size;
          size = backtrace(array, 50);
          backtrace_symbols_fd(array, size, 2);
      }
      for (;;) sleep(9999);
  }
  #endif