说在前面
最近在项目中遇到大型程序出现SIGSEGV ,一直不知道用core dump工具来调试程序,花了近一周的时间,才定位问题,老大很生气,后果很严重,呵呵,事后仔细学习了这块的知识,了解一点core dump的知识。
在使用半导体作为内存的材料前,人类是利用线圈当作内存的材料(发明者为王安),线圈就叫作core ,用线圈做的内存就叫作“core memory”。(线圈的单词应该是coil,呵呵)如今,半导体工业澎勃发展,已经没有人用线圈当内存了,不过,在许多情况下,人们还是把内存叫作“core”。 所以注意了:这里的core不是核心,而是内存。不过结合实际来看,好像也有点“内核所占内存”的意思。
core dump又是什么东东? 我们在开发(或使用)一个程序时,最怕的就是程序莫明其妙地挂掉。虽然系统没事,但我们下次仍可能遇到相同的问题。于是,这时操作系统就会把程序挂掉时的 内存内容写入一个叫做core的文件里(这个写入的动作就叫dump,dump的英语意思是垃圾、倾倒。从这里来看,这些内存的内容是程序错误运行的结果,所以算是垃圾,把他弄出来就好比从大的内存池里“倾倒”。),以便于我们调试。这个过程,因此叫做core dump.在嵌入式系统中,有时core dump直接从串口打印出来,结合objdump查找ra和epa地址,运用栈回溯,可以找到程序出错的地方。
如何使系统产生core dump文件
在一般Linux系统中,程序出错后,默认是不会产生core dump文件的,通过ulimit -c来查看core dump文件的大小,一般开始是0,可以设置core文件大小,ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。
如何修改生成core文件的名称
有时core文件生成的名字一样的话,下一次生成总为覆盖上一次的结果,此时 需要对配置文件进行修改,配置文件为:/proc/sys/kernel/core_pattern
一般 echo "|/usr/share/apport/apport %p %s %c %d %P %E “ > /proc/sys/kernel/core_pattern
用gdb 查看core 文件判断程序出错的位置
gdb [exec file] [core file]
如我的:
gdb ./demo core.50382 其中** 50382表示对应程序的进程ID**
只有用bt 直接跳转到出错的位置:(错误是越下越靠近我们书写代码出错的位置)