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对应状况，全部泄漏点位置给出，这一点在其余工具很难作到，十分好用。