一篇文章轻松学会使用gdb调试程序的core文件（调试全过程）

在Linux环境中，使用GDB（GNU调试器）来调试程序的core文件是一种常见的方法来诊断程序崩溃的原因。Core文件是程序异常终止时的内存镜像，包含了程序崩溃时的许多有用信息，如调用栈、寄存器状态等。以下是一个详细的操作教程，介绍如何使用GDB来调试core文件。

一、生成Core文件

1、程序异常崩溃的情况

配置系统生成Core文件（用于程序异常崩溃的情况，设置完之后，等待程序异常崩溃生成core文件）

① 设置Core文件大小

打开终端，并输入以下命令来移除core文件大小的限制：

ulimit -c unlimited

这条命令将当前shell的core文件大小限制设置为无限制。这意味着无论程序崩溃时需要多大的core文件，系统都会生成。

② 检查当前的Core文件设置

要查看当前的core文件生成设置，可以使用以下命令：

ulimit -a

这会列出所有与ulimit相关的限制，包括core文件的大小限制。

③ 设置Core文件的生成位置

默认情况下，core文件通常在程序崩溃的当前工作目录中生成。可以通过设置/proc/sys/kernel/core_pattern来改变这一行为，指定一个全局的路径用于存储core文件。例如，设置core文件生成在/cores目录：

echo "/cores/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern

这里的%e、%p和%t是模板，分别代表可执行文件的名称、进程ID和时间戳。这样做可以帮助你更容易地找到和区分不同程序生成的core文件。（建议可以把这一行命令最后的目录改一下，前面的直接使用）

④ 创建Core文件存储目录

如果已经指定了一个特定目录用于存储core文件，确保这个目录存在并且具有适当的权限：

sudo mkdir /cores
sudo chmod 777 /cores

这样设置后，所有用户都可以写入该目录。

⑤ 永久修改设置

上述通过ulimit命令和/proc/sys/kernel/core_pattern的修改只对当前会话有效。要永久修改这些设置，需要在系统级别进行配置：

对于ulimit，你可以在/etc/security/limits.conf添加如下行：

* soft core unlimited
* hard core unlimited

对于core_pattern，你可以将上述echo命令添加到系统启动脚本中，例如/etc/rc.local。

通过这些步骤，你的系统将被正确配置，以确保在程序崩溃时生成core文件。这为使用GDB进行后续的调试工作提供了基础。

2、程序不崩溃的情况(gcore)

使用gcore，gcore 是一个用于生成正在运行的进程的内存转储文件（core dump）的工具，通常用于调试和分析程序阻塞或其他问题。下面详细介绍如何使用 gcore 来生成 core文件的步骤，以及如何实际操作：

① 安装 gcore

首先，确保系统中安装了 gcore。gcore 通常包含在 gdb 软件包中，可以使用系统的包管理器来安装它。例如，在基于 Debian 的系统（如 Ubuntu）上，可以使用以下命令安装：

sudo apt-get install gdb

在 Red Hat 或 CentOS 系统上，使用：

sudo yum install gdb

② 使用 gcore 生成 core 文件

1、找到进程 ID：
在生成 core 文件之前，需要知道要转储的进程的进程 ID（PID）。可以使用 ps 命令查找进程 ID。例如，如果想查找名为 myapp 的应用程序的 PID：

ps aux | grep myapp

这将输出与 myapp 相关的进程列表，可以从中找到 PID。
2、生成 core 文件：
使用 gcore 命令加上想要转储的进程的 PID。例如，如果进程的 PID 是 1234：

sudo gcore 1234

这将在当前目录下创建一个名为 core.1234 的文件。

2、安装GDB

如果还没有安装GDB，可以通过Linux发行版的包管理器来安装它。例如，在Ubuntu上，可以使用：

sudo apt-get install gdb

3、使用GDB打开Core文件

当有了core文件和相应的可执行文件之后，使用以下命令来启动GDB：

gdb <path-to-executable> <path-to-core-file>

例如：

gdb /home/user/myprogram /home/user/core.1234

4、分析Core文件

一旦GDB加载了core文件，可以使用多种命令来分析问题：

bt 或 backtrace: 显示当前线程的调用栈跟踪。
info threads: 列出所有线程。
thread n: 切换到指定的线程号，n为指定的线程号
list: 显示当前执行的源代码。
print x: 打印变量或表达式的值，x为变量或表达式
frame f: 切换到特定的栈帧。f为指定的栈帧号
thread apply all bt: 打印所有堆栈信息

很重要一点：GDB可以设置日志，设置完日志文件、打开日志开关之后GDB调试的所有内容都会输出到设置的日志文件中去，方便查看堆栈信息等内容，例如：

# 设置gdb日志路径及名称  
# 这个命令会自动创建日志文件但是不会创建目录，所以要保证这个路径的目录都存在
(gdb)set logging file /opt/log/log.txt

# 打开日志  
(gdb)set logging on

# 打印所有堆栈信息
(gdb)thread apply all bt
(gdb)c

之后就可以在/opt/log/log.txt文件中看到所有堆栈信息。

5、查找错误原因

利用上述工具，你可以开始追踪崩溃的具体原因了。通常，错误会因为非法内存访问、逻辑错误或资源问题（如内存耗尽）引起。具体步骤如下：

① 确定崩溃位置：使用bt查看崩溃的函数调用栈。
② 变量审查：在崩溃点查看关键变量的值，特别是指针、数组索引和迭代器。
③ 条件检查：查看崩溃点附近的条件语句，确认逻辑是否正确。

6、示例命令

这里是一些可能会用到的GDB命令示例：

# 查看崩溃时的栈帧
(gdb) bt

# 打印变量值
(gdb) print variable_name

# 显示当前执行点的源代码
(gdb) list

# 更改变量值  可以试图在调试时更改变量的值来测试不同的假设
(gdb) set var variable_name = new_value

# 查看当前的CPU寄存器值
(gdb) info registers

# 退出GDB
(gdb) quit

GDB更多基本使用方法推荐“烽起黎明”大佬一篇的帖子，看完一定能收获满满 Linux | 调试器GDB的详细教程【纯命令行调试】。

7、退出GDB

输入 quit (q) 回车或者按 Ctrl-D 退出GDB。

使用GDB调试core文件需要一定的耐心和细心，因为需要深入了解程序的内部工作。不过，随着经验的积累，你会越来越熟练地使用这些技巧来定位和解决问题。