利用 GDB & Core Dump 来定位程序出错的位置

转载自，

Core Dump详解

gdb结合coredump定位崩溃进程

1. 什么是Core：

Sam之前一直以为Core Dump中Core是 Linux Kernel的意思. 今天才发现在这里，Core是另一种意思：

在使用半导体作为内存的材料前，人类是利用线圈当作内存的材料（发明者为王安），线圈就叫作 core ，用线圈做的内存就叫作 core memory。如今 ，半导体工业澎勃发展，已经没有人用 core memory 了，不过，在许多情况下， 人们还是把记忆体叫作 core 。

 

2. 什么是Core Dump：

我们在开发（或使用）一个程序时，最怕的就是程序莫明其妙地当掉。虽然系统没事，但我们下次仍可能遇到相同的问题。于是这时操作系统就会把程序当掉 时的内存内容 dump 出来（现在通常是写在一个叫 core 的 file 里面），让 我们或是 debugger 做为参考。这个动作就叫作 core dump。

 

3. Core Dump时会生成何种文件：

Core Dump时，会生成诸如 core.进程号 的文件。

 

4. 为何有时程序Down了，却没生成 Core文件。

Linux下，有一些设置，标明了resources available to the shell and to processes。 可以使用

#ulimit -a 来看这些设置。 (ulimit是bash built-in Command)

              -a     All current limits are reported
              -c     The maximum size of core files created
              -d     The maximum size of a process鈥檚 data segment
              -e     The maximum scheduling priority ("nice")
              -f     The maximum size of files written by the shell and its children
              -i     The maximum number of pending signals
              -l     The maximum size that may be locked into memory
              -m     The maximum resident set size (has no effect on Linux)
              -n     The maximum number of open file descriptors (most systems do not allow this value to be set)
              -p     The pipe size in 512-byte blocks (this may not be set)
              -q     The maximum number of bytes in POSIX message queues
              -r     The maximum real-time scheduling priority
              -s     The maximum stack size
              -t     The maximum amount of cpu time in seconds
              -u     The maximum number of processes available to a single user
              -v     The maximum amount of virtual memory available to the shell
              -x     The maximum number of file locks

 从这里可以看出，如果 -c是显示：core file size          (blocks, -c)

如果这个值为0，则无法生成core文件。所以可以使用：

#ulimit -c 1024  或者 #ulimit -c unlimited  来使能 core文件。

如果程序出错时生成Core 文件，则会显示Segmentation fault (core dumped)。

 

5. Core Dump的核心转储文件目录和命名规则:
/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0

 

 

6. 如何使用Core文件：

在Linux下，使用：

#gdb -c core.pid program_name

就可以进入gdb模式。

 

输入where，就可以指出是在哪一行被Down掉，哪个function内，由谁调用等等。

(gdb) where

 

或者输入 bt。

(gdb) bt

 

7. 如何让一个正常的程序down:

#kill -s SIGSEGV pid

 

 

8. 察看Core文件输出在何处：

存放Coredump的目录即进程的当前目录，一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动，则脚本可能会修改当前目录，这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/<进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。

Linux环境下经常遇到某个进程挂掉而找不到原因，我们可以通过生成core file文件加上gdb来定位。

 

如何产生core file?

我们可以使用ulimit这条命令对core file文件的大小进行设定。

一般默认情况下，core file的大小被设置为了0，这样系统就不dump出core file了。

这时用如下命令进行设置：
ulimit -c unlimited
这样便把core file的大小设置为了无限大，同时也可以使用数字来替代unlimited，对core file的上限值做更精确的设定。

 

生成的core file在哪里?

core file生成的地方是在/proc/sys/kernel/core_pattern文件定义的。

改动到生成到自己定义的目录的方法是：
echo "pattern" > /proc/sys/kernel/core_pattern
并且只有超级用户可以修改这两个文件。

"pattern"类似我们C语言打印字符串的格式，相关标识如下：

%%: 相当于%
%p: 相当于<pid>
%u: 相当于<uid>
%g: 相当于<gid>
%s: 相当于导致dump的信号的数字
%t: 相当于dump的时间
%h: 相当于hostname
%e: 相当于执行文件的名称

这时用如下命令设置生成的core file到系统/tmp目录下，并记录pid以及执行文件名

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

 

测试如下代码

?

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h>   int func( int *p) {          *p = 0; }   int main() {          func(NULL);          return 0; }

 

生成可执行文件并运行

gcc -o main a.c

root@ubuntu:~# ./main
Segmentation fault (core dumped) 

<-----这里出现段错误并生成core文件了。

在/tmp目录下发现文件core-main-10815 

 

如何查看进程挂在哪里了?

我们可以用

gdb main /tmp/core-main-10815 

查看信息，发现能定位到函数了

Program terminated with signal 11, Segmentation fault.
#0  0x080483ba in func ()

 

如何定位到行?

在编译的时候开启-g调试开关就可以了

gcc -o main -g a.c

gdb main /tmp/core-main-10815 

最终看到的结果如下，好棒。

Program terminated with signal 11, Segmentation fault.
#0  0x080483ba in func (p=0x0) at a.c:5
5          *p = 0;

 

总结一下，需要定位进程挂在哪一行我们只需要4个操作，

ulimit -c unlimited

echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern

gcc -o main -g a.c

gdb main /tmp/core-main-10815 

就可以啦。

 

补充说明：

相关常用gdb命令

1,(gdb) backtrace /* 查看当前线程函数栈回溯 */

以上面的例子为例

Program terminated with signal 11, Segmentation fault.

#0  0x080483ba in func (p=0x0) at main.c:5

5 *p = 0;

(gdb) backtrace

#0  0x080483ba in func (p=0x0) at main.c:5

#1  0x080483d4 in main () at main.c:10

如果是多线程环境下(gdb) thread apply all backtrace /* 显示所有线程栈回溯 */

 

2,(gdb) print [var] /* 查看变量值 */

(gdb) print p

$1 = (int *) 0x0

(gdb) print &p

$2 = (int **) 0xbf96d4d4

 

3,(gdb) x/FMT [Address] /* 根据格式查看地址指向的值 */

其中

FMT is a repeat count followed by a format letter and a size letter.

Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),

  t(binary), f(float), a(address), i(instruction), c(char) and s(string).

Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).

The specified number of objects of the specified size are printed

according to the format.

 

(gdb) x/d 0xbf96d4d4

0xbf96d4d4: 0

(gdb) x/c 0xbf96d4d4

0xbf96d4d4: 0 '\000'

 

另外能导致产生core file文件的信号有以下10种

SIGQUIT：终端退出符

SIGILL：非法硬件指令

SIGTRAP：平台相关的硬件错误，现在多用在实现调试时的断点

SIGBUS：与平台相关的硬件错误，一般是内存错误

SIGABRT：调用abort函数时产生此信号，进程异常终止

SIGFPE：算术异常

SIGSEGV：segment violation，无效内存引用

SIGXCPU：超过了cpu使用资源限制（setrlimit）

SIGXFSZ：超过了文件长度限制（setrlimit）

SIGSYS：无效的系统调用