概述

gdb我们大家应该已经很熟悉了，在使用gdb的场景一种是attach在running的进程，但是这种可能会影响进程的运行甚至我们在生产环境导致环境出现意想不到的问题，所以一般不建议在生产环境直接使用gdb，那我们如何调试进程呢？下面浅述一下自己的方法。

回答上面的问题一般就是进程在发生一些错误导致panic时产生了一个coredump文件，我们离线分析，这样是最安全的，下面说一下如何正确设置可以使的环境产生coredump文件。

环境设置

• 确保我们正确设置了配置

  [root@localhost test-zjp]# ulimit -a
  core file size          (blocks, -c) unlimited
  data seg size           (kbytes, -d) unlimited
  scheduling priority             (-e) 0
  file size               (blocks, -f) unlimited
  pending signals                 (-i) 3178
  max locked memory       (kbytes, -l) unlimited
  max memory size         (kbytes, -m) unlimited
  open files                      (-n) 1024
  pipe size            (512 bytes, -p) 8
  POSIX message queues     (bytes, -q) 819200

其中比较主要的是 core file size (blocks, -c) unlimited，可以通过如下命令行打开或者关闭

• Enable

  [root@localhost test-zjp]# ulimit -c unlimited
  [root@localhost test-zjp]# ulimit -a
  core file size          (blocks, -c) unlimited

• Disable

  [root@localhost test-zjp]# ulimit -c 0
  [root@localhost test-zjp]# ulimit -a
  core file size          (blocks, -c) 0

  当然也可以设置一个具体的数值，具体可以查看man信息了解，这里就不再赘述。

• 设置coredump的存放路径
  默认的路径是如下：

  [root@localhost test-zjp]# sysctl -A | grep kernel.core_pattern
  kernel.core_pattern = core

  这代表是coredump文件存放在二进制运行的路径下，这对于系统的一些服务产生不太好查找，因此建议设置这样

  [root@localhost test-zjp]# sysctl -w kernel.core_pattern=/var/crash/core.%u.%e.%p                                                                                                                                  
  kernel.core_pattern = /var/crash/core.%u.%e.%p 

  之后生成的文件都会存在/var/crash文件下，命名个是类似core.0.a.out.7389

测试

上面的步骤设置完成后，当程序发生panic就会自动生成coredump文件，我们就可以直接debug该文件查找到问题的元凶，具体如下：

[root@localhost test-zjp]# gcc -g hello.c 
[root@localhost test-zjp]# ./a.out 
Segmentation fault (core dumped)

进程发生段错误

Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000004004fd in main () at hello.c:13
13              *a = 1;
(gdb) l
8       }*p_st,n_st;
9
10      void main(void)
11      {
12              int *a = NULL;
13              *a = 1;
14              while(1);
15              printf("helloword\n");
16      }
(gdb) 

上面说的都是在进程发生类似段错误系统才会发signal，产生coredump文件。

但是我们经常遇到进程hang在某个地方，没有产生coredump文件该如何处理呢？
如果有一个工具可以手动产生正在running进程的coredump文件那该多好，现在就有这个命令gcore(install gdb)，例如一个程序一直运行在which(1),通过手动生成coredump文件

[root@localhost ~]# gcore `pidof a.out`
main () at hello.c:13
13              while(1);
Saved corefile core.8374
[Inferior 1 (process 8374) detached]

gdb该文件可以看到一直hang在line 13行while(1)

Core was generated by `./a.out'.
#0  main () at hello.c:13
13              while(1);
(gdb) bt
#0  main () at hello.c:13

可以看到我们也可以通过主动生成coredump文件debug进程问题，如果进程跑飞、hang住等问题是非常有效的一个方式。

ps:这里主要介绍gdb的一下应用场景，具体使用方法大家可以google或者help学习，这里不再赘述。

参考链接

https://zhuanlan.zhihu.com/p/46605905
http://hutaow.com/blog/2013/10/25/linux-core-dump/