1. 准备工作

安装 GDB
在大多数 Linux 发行版上，执行：
```
sudo apt-get update
sudo apt-get install gdb
```
确保有足够磁盘空间
Core dump 文件可能较大，请提前检查磁盘剩余空间：
```
df -h .
```
可选：使用 tmux 或 screen
为避免 SSH 断开导致 GDB 会话中断，推荐先启动会话管理工具：
```
tmux new -s redis-debug
```
或
```
screen -S redis-debug
```

2. Redis 编译（无优化模式）

默认 Redis 会使用 -O2 优化编译，这会影响 GDB 对源代码和变量的精准解析。建议在调试时使用无优化版本：

cd redis-source-directory
make distclean      # 清理旧编译产物
make noopt          # 使用 noopt 模式编译

说明：若生产环境中无法重启或重新编译，也可直接对已在运行的优化版二进制附加 GDB，调试仍然有效，只是符号信息较少。

3. 获取 Redis 进程 PID

使用 redis-cli 快速查询当前运行实例的进程号（PID）：

redis-cli info | grep process_id
# 输出示例：process_id:58414

4. 附加 GDB 到 Redis 进程

在命令行中执行：

gdb /usr/local/bin/redis-server 58414

启动后，GDB 会自动附加并阻塞进程，您只需在 (gdb) 提示符下输入：

continue

让 Redis 继续运行。此时，Redis 性能几乎不受影响，您可以安全地等待下次崩溃触发。

5. 触发崩溃并收集调试信息

当 Redis 崩溃时（例如在 GDB 会话中执行 DEBUG SEGFAULT 测试），GDB 会中断并给出崩溃位置：

Program received signal SIGSEGV, Segmentation fault.
0x000000010d26cfd4 in debugCommand (c=0x7ffc32005000) at debug.c:220
220         *((char*)-1) = 'x';

5.1 打印堆栈回溯

(gdb) bt
#0  debugCommand (c=0x7ffc32005000) at debug.c:220
#1  0x000000010d246d63 in call (c=0x7ffc32005000) at redis.c:1163
#2  0x000000010d247290 in processCommand (c=0x7ffc32005000) at redis.c:1305
#3  ...

5.2 打印寄存器状态

(gdb) info registers
rax            0x0      0
rbx            0x7ffc32005000  140721147367424
rcx            0x10d2b0a60     4515891808
...
rip            0x10d26cfd4 <debugCommand+68>
eflags         0x10246  66118

请务必在报告中同时包含完整的堆栈回溯（bt 输出）和寄存器信息（info registers 输出）。

6. 导出 Core 文件

Core 文件能够重现崩溃时的内存快照，便于开发者在本地深入分析：

(gdb) gcore
Saved corefile core.58414
(gdb) quit

生成的 core.58414 文件即为崩溃时的内存镜像。

7. 准备并提交给 Redis 核心团队

在向 Redis 在 GitHub Issues 提交问题或邮件报告时，请附上以下内容：

Redis 可执行文件
您所用的 redis-server 二进制，编译选项需一致。
堆栈回溯 & 寄存器输出
bt 与 info registers 的完整文本。
Core dump
core.58414 文件。
环境信息
- 操作系统版本（例如 uname -a 输出）
- GCC 版本（例如 gcc --version）
- Redis 版本（redis-server --version）