linux core dump 文件 gdb分析

core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump. (linux中如果内存越界会收到SIGSEGV信号，然后就会core dump)

在程序运行的过程中，有的时候我们会遇到Segment fault(段错误)这样的错误。这种看起来比较困难，因为没有任何的栈、trace信息输出。该种类型的错误往往与指针操作相关。往往可以通过这样的方式进行定位。

一 造成segment fault，产生core dump的可能原因

1.内存访问越界

a) 由于使用错误的下标，导致数组访问越界

b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符

c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

2 多线程程序使用了线程不安全的函数。

3 多线程读写的数据未加锁保护。对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump

4 非法指针

a) 使用空指针

b) 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump.

5 堆栈溢出.不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

二 配置操作系统使其产生core文件

首先通过ulimit命令查看一下系统是否配置支持了dump core的功能。通过ulimit -c或ulimit -a，可以查看core file大小的配置情况，如果为0，则表示系统关闭了dump core。可以通过ulimit -c unlimited来打开。若发生了段错误，但没有core dump，是由于系统禁止core文件的生成。

解决方法:
$ulimit -c unlimited　　（只对当前shell进程有效）
或在~/.bashrc　的最后加入： ulimit -c unlimited （一劳永逸）

# ulimit -c

0

$ ulimit -a

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

file size (blocks, -f) unlimited

三 用gdb查看core文件

发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.

gdb [exec file] [core file]

如: gdb ./test test.core

使用gdb 调试方法，首先要在gcc编译时加入-g选项。

调试core文件，在Linux命令行下：gdb pname corefile。

例如，程序名为controller_tester，core文件为core.3421，则为：gdb controller_tester core.3421。

这样进入了gdb core调试模式。

追踪产生segmenttation fault的位置及代码函数调用情况：

gdb>bt

这样，一般就可以看到出错的代码是哪一句了，还可以打印出相应变量的数值，进行进一步分析。

gdb>print 变量名

之后，就全看各位自己的编程功力与经验了，gdb已经做了很多了。

2. 对于结构复杂的程序，如涉及模板类及复杂的调用，gdb得出了出错位置，似乎这还不够，这时候要使用更为专业的工具——valgrind。

valgrind是一款专门用作内存调试，内存泄露检测的开源工具软件，valgrind这个名字取自北欧神话英灵殿的入口，不过，不能不承认，它确实是Linux下做内存调用分析的神器。一般Linux系统上应该没有自带valgrind，需要自行进行下载安装。

下载地址：http://valgrind.org/downloads/current.html

进入下载文件夹，分别执行(需要root权限，且必须按默认路径安装，否则有加载错误)：

./configure

make

make install

安装成功后，使用类似如下命令启动程序：

valgrind --tool=memcheck --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes --log-file=memchecklog ./controller_test

其中，–log-file=memchecklog指记录日志文件，名字为memchecklog；–tool=memcheck和–leak-check=full用于内存检测。

可以得到类似的记录：

==23735==
==23735== Thread 1:
==23735== Invalid read of size 4
==23735== at 0x804F327: ResourceHandler<HBMessage>::~ResourceHandler() (ResourceHandler.cpp:48)
==23735== by 0x804FDBE: ConnectionManager<HBMessage>::~ConnectionManager() (ConnectionManager.cpp:74)
==23735== by 0×8057288: MainThread::~MainThread() (MainThread.cpp:73)
==23735== by 0x8077B2F: main (Main.cpp:177)
==23735== Address 0×0 is not stack’d, malloc’d or (recently) free’d
==23735==

可以看到说明为无法访问Address 0x0，明显为一处错误。

这样valgrind直接给出了出错原因以及程序中所有的内存调用、释放记录，非常智能，在得知错误原因的情况下，找出错误就效率高多了。

再说一句，valgrind同时给出了程序的Memory Leak情况的报告，给出了new-delete对应情况，所有泄漏点位置给出，这一点在其他工具很难做到，十分好用。

原文作者：ThinkDiff

原文地址：linux core dump 文件 gdb分析（版权归原文作者所有，侵权留言联系删除）