[GDB] core文件

[GDB] core文件

1 简介

在调试栈溢出之类的漏洞时，经常会因为跳转产生程序段错误，在实际的编码过程中，由于空指针、野指针的访问，也容易引发程序段错误（segment fault）。在这种情况下，可以使用gdb结合coredump文件重新快速定位到问题发生的地方。

主要是有时候在调试漏洞，发生segment fault，菜鸡只有每次重新再输入数据去触发，就在想，有没有方法可以快速进行调试、复现发生错误的场景。

2 coredump

2.1 coredump文件定义

coredump是应用程序在运行过程中，由于一些原因导致程序异常终止，操作系统将异常发生时的状态信息记录为一个coredump文件。在coredump文件中，主要包含了应用程序的内存信息、寄存器状态、堆栈地址、函数调用上下文，开发人员、调试人员通过分析这些信息，可以确定程序异常发生时的调用位置。

在开发过程中，由于代码质量的问题，错误发生可能具有不确定性，一方面程序发生错误的时候，没有记录下有用的可能导致错误的数据信息；另一方面是问题复现的概率比较低，复现的条件具有不确定性。使用了coredump文件，其中包含的程序奔溃时的具体状态信息：栈的内容、CPU寄存器的内容、内存信息，那么就足够用来分析产生奔溃的原因了。

Qu：此处是把完整的内存都保留下来了么？肯定不是，那么保存的机制又是什么呢？只保存可写部分么，因为不可写部分直接加载可执行文件到内存就可以了

2.2 coredump产生的场景

大多数情况下，应用程序产生的异常都和内存有关，总结大概如下：

1. 内存访问越界

   • 数据下标越界
   • 读写超出动态内存申请范围
   • 字符串没有结束符，一些函数依赖字符串结束符，例如strcpy、strcmp、sprintf

2. 访问非法指针

   • 空指针（未申请内存）
   • 野指针（指向已经释放的内存）
   • 重复释放指针（内存）
   • 指针强制转换（指针的强制转换需要谨慎，可能因为对齐、起始地址等问题引起内存访问错误）

3. 堆栈溢出

   分配大量局部变量、多重函数调用、函数递归的层数太深等，可能导致堆栈溢出。

4. 多线程访问

   • 调用不可重入函数
   • 共享数据未互斥访问

2.3 开启coredump

• 查看是否开启coredump

  系统默认是不开启coredump记录功能，执行命令ulimit -c查看是否开启，如果未开启返回0

  ➜  ~ ulimit -c
  0
  

  </