1. coredump

1.1 coredump简介

core dump，又称为核心转储，是操作系统在进程收到某些信号而终止运行时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件

coredump文件含有当进程被终止时内存、CPU寄存器和各种函数调用堆栈信息等，可以供后续开发人员进行调试

cat /proc/sys/kernel/core_pattern

个人的如下：
在这里插入图片描述

我们可以通过修改kernel的参数来指定内核生成的coredump文件的文件名。常见设置如下：

//在终端键入下列命令
echo "/data/coredump/core.%e.%p" > /proc/sys/kernel/core_pattern

在这条命令中，/data/coredump是你自己指定的存放coredump文件的路径，所有产生的coredump文件将会存放在这里，%e表示程序的文件名，%p表示进程的ID（当然还有一些其他的参数可以设置，例：%t显示创建的时间）

在这里个人蠢了一下，没有创建存放的目录即/data/coredump，导致后面一直无法生成coredump文件，后面加上mkdir /data/coredump即创建成功，os：真是被自己蠢哭了

//当前有效的修改
ulimit -c [size]  //这里size一般修改为unlimited
//可以使用ulimit -a访问详细信息
ulimit -a

在这里插入图片描述

//修改/etc/profile配置
vim /etc/profile
//添加 ulimit -c unlimited

在这里插入图片描述

然后执行source /etc/profile或者关闭重新开启就能生效了

具体原因可能是：1.由于使用错误下标，导致数组访问越界
2.搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符
3.使用strcpy，strcat，sprintf等字符串操作函数时，容易出现读写越界的情况

//测试文件
#include <iostream>
int main()
{
    int b = 1;
    int* a;
    *a = b;
    return 0;
}

很明显a指针指向错误，会产生段错误，首先编译该文件，执行文件：

g++ -g -o test test.cpp    //编译得到可执行文件test
./test   //运行可执行文件

得到如下结果，显示生成了coredump文件：
在这里插入图片描述
现在去存储coredump文件的目录查找该coredump，并将其移出到表目录进行分析：

cd /data/coredump    //自己设置的存储目录
ls -l       //列出文件
cp core.test.32469 /home/ubuntu    //拷贝core文件到表目录，test为文件名，32469为进程ID

进入存储目录查看coredump文件：
在这里插入图片描述
移动到表目录：

该文件也是ELF文件，可以采用readelf查看该文件：

//例：
readelf -h core.test.32469

在这里插入图片描述

当我们使用gdb调试时，是先从可执行文件中读取符号表信息，然后再读取core文件。这个步骤会让人疑问，难道core文件中无符号表信息么？不与可执行文件一同执行可以么？
我们可以直接查看core文件是否含有符号表信息，执行以下命令：

objdump -x core.test.32469 | tail

在这里插入图片描述
其中可以看到SYMBOL TABLE: no symbols,表明当前的ELF文件中没有符号表信息

接下来利用gdb进行分析（须带可执行文件）：

gdb test core.test.32469

可以看到core在第六行：
在这里插入图片描述
接着打印a和b的值：

可以看到指针a指向的明显不是b的地址，所以引发了段错误

到这里我们的gdb调试分析coredump就结束了，想了解更多有关gdb调试的可以访问本人的这篇文章【linux】gdb调试

------------------------------------------get------------------------------------------------------

1.coredump文件
2.使用gdb调试分析coredump