coredump产生的几种可能:

  • 内存访问越界
    • 数组访问越界
    • 搜索字符串时,以字符串结束符来判断字符串是否结束,但该字符串无结束符
    • 用strcpy, strcat, sprintf, strcmp,strcasecmp等字符串操作函数,将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。
  • 多线程使用线程不安全的函数
  • 多线程读写数据未加锁
  • 非法指针
    • 使用空指针
    • 随意使用reinterpret_cast
  • 堆栈溢出
    • 不要使用大的局部变量(因为局部变量都分配在栈上),这样容易造成堆栈溢出,破坏系统的栈和堆结构,导致出现莫名其妙的错误。

前提

产生coredump文件需要如下前提:

查询core file size 是否为0 , 若0,则不会产生core文件,单位为blocks【1 blocks = 512 bytes 】

  1. ulimit -a # 查询系统配置文件大小
  2. ulimit -c unlimited # 设置core file size 大小 ,此时仅对当前的会话有效
  3. #若需要全局配置
  4. vim ~/etc/profile
  5. #在其中加入
  6. ulimit -c unlimited

image.png

利用gdb定位coredump

gdb常用命令

l list 显示源代码,可看到行号
b x break x为行号,表示在对应行号设置断点;
d <函数名 | 行号 | 地址> delete 表示删除对应断点
i b info breakpoint 显示所有断点
p <变量名> print x为变量名,打印x的值
r run 执行到断点处
n step over 单步追踪
s step into 单步进入
c continue 继续执行
q quit 退出gdb
bt backtrace 列出函数调用栈信息

分析gdb core文件

1352287964_7192.jpg
从第2个红色框中,可以查到当前程序终止信息,根据信息,该程序因为SIG 11而中止。
通过bt查询函数的调用栈可知,程序奔溃在core_test1()处