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 大小   ，此时仅对当前的会话有效
  4. #若需要全局配置
  5. vim ~/etc/profile
  6. #在其中加入
  7. 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()处