Linux gdb分析core dump文件

谁借莪１个温暖的怀抱￠ 2021-12-15 12:09 633阅读 0赞

文章目录1. coredump1.1 coredump简介1.2 coredump的文件存储路径1.3 coredump产生的条件1.4 coredump产生原因2. 测试生成coredump  
1. coredump  
1.1 coredump简介  
core dump，又称为核心转储，是操作系统在进程收到某些信号而终止运行时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件  
coredump文件含有当进程被终止时内存、CPU寄存器和各种函数调用堆栈信息等，可以供后续开发人员进行调试  
1.2 coredump的文件存储路径

一般情况使用下列命令可以看到core文件的存储位置：

cat /proc/sys/kernel/core\_pattern  
1  
个人的如下：

我们可以通过修改kernel的参数来指定内核生成的coredump文件的文件名。常见设置如下：  
//在终端键入下列命令  
echo "/data/coredump/core.%e.%p" > /proc/sys/kernel/core\_pattern  
12  
在这条命令中，/data/coredump是你自己指定的存放coredump文件的路径，所有产生的coredump文件将会存放在这里，%e表示程序的文件名，%p表示进程的ID（当然还有一些其他的参数可以设置，例：%t显示创建的时间）

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

1.3 coredump产生的条件

首先确定当前会话的能生成的coredump文件大小，如果为0则不会产生对应的coredump文件：

这个时候就需要修改和设置了，可以使用下列两种方式设置：

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

上述修改方式在关闭后再重启就无效了，所以采用下列方式使它永久有效：

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

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

1.内存访问越界

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

2.多线程程序使用了线程不安全的函数  
3.多线程读写的数据未枷锁保护  
4.非法指针、包括使用空指针或随意使用指针转换  
5.堆栈溢出

2. 测试生成coredump  
//测试文件  
\#include <iostream>  
int main()  
\{  
    int b = 1;  
    int\* a;  
    \*a = b;  
    return 0;  
\}  
123456789  
很明显a指针指向错误，会产生段错误，首先编译该文件，执行文件：  
g++ -g -o test test.cpp    //编译得到可执行文件test  
./test   //运行可执行文件  
12  
得到如下结果，显示生成了coredump文件：

现在去存储coredump文件的目录查找该coredump，并将其移出到表目录进行分析：  
cd /data/coredump    //自己设置的存储目录  
ls -l       //列出文件  
cp core.test.32469 /home/ubuntu    //拷贝core文件到表目录，test为文件名，32469为进程ID  
123  
进入存储目录查看coredump文件：

移动到表目录：

该文件也是ELF文件，可以采用readelf查看该文件：  
//例：  
readelf -h core.test.32469  
12

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

其中可以看到SYMBOL TABLE:  no symbols,表明当前的ELF文件中没有符号表信息  
接下来利用gdb进行分析（须带可执行文件）：  
gdb test core.test.32469  
1  
可以看到core在第六行：

接着打印a和b的值：

可以看到指针a指向的明显不是b的地址，所以引发了段错误  
到这里我们的gdb调试分析coredump就结束了，想了解更多有关gdb调试的可以访问本人的这篇文章【linux】gdb调试  
\------------------------------------------get------------------------------------------------------  
1.coredump文件  
2.使用gdb调试分析coredump  
\---------------------  
  
原文：https://blog.csdn.net/qq\_38790716/article/details/85107405

转载于:https://www.cnblogs.com/xibuhaohao/p/11101502.html