gcore转储进程内存

gcore 是 GDB 套件中的一个实用工具，用于在不停止或崩溃程序的情况下，为正在运行的进程生成内存快照（Core Dump）。这在调试线上“卡死”或难以复现的逻辑问题时非常高效。

1. 基本用法

在终端中直接运行，最简单的语法如下：

gcore <PID>

获取 PID: 使用 ps -ef | grep 程序名 或 pidof 程序名 找到目标进程 ID。
生成快照: 执行 gcore <PID>。此时进程会短暂暂停，待文件写入磁盘后恢复运行。
使用 GDB 分析:
```
gdb <可执行程序路径> <生成的core文件>
```
进入 GDB 后，可以使用 bt 查看调用栈，或使用 info threads 查看所有线程状态。

如果你已经在使用 GDB 调试（attach）某个进程，可以直接在 GDB 提示符下输入：

(gdb) generate-core-file [文件名]
# 或者简写
(gdb) gcore [文件名]

这与外部的 gcore 工具效果一致。

传统的 Core Dump 是程序崩溃时的“验尸报告”，而 gcore 生成的是“活体切片”。

它的主要用途可以概括为以下四个核心场景：

1). 诊断“程序卡死”（Deadlock / Hang）

这是 gcore 最经典的使用场景。当程序没有崩溃，但不再响应请求（比如死锁、无限循环、等待信号量）时：

你不能等到它崩溃（因为它可能永远卡在那）。
你可以用 gcore <pid> 拍个快照，然后把这个快照拉回本地环境，用 thread apply all bt 查看所有线程的调用栈，找出到底是哪个锁导致了卡死。

2). 线上环境的“非破坏性”采样

在线上（Production）环境直接用 GDB 挂载（attach）进行交互式调试是非常危险的，因为 GDB 会暂停（Stop）进程。

3). 捕捉“中间状态”或内存泄漏

当你怀疑程序运行到某个阶段逻辑有问题，或者发现内存占用异常上升时：

4). 容错与“时光倒流”

在进行一些可能破坏程序状态的危险 GDB 操作（比如手动调用 call 改变变量值）之前，先执行 gcore：

总结：它和传统 Core Dump 的本质区别

磁盘空间: Core 文件是进程内存的完整镜像，如果进程占用内存很大（如数 GB），生成的文件也会同样大，请确保目标磁盘空间充足。
权限: 通常需要 root 权限或与目标进程相同的用户权限才能执行转储。
ptrace 限制: 某些系统可能会限制 ptrace 调用（如设置了 /proc/sys/kernel/yama/ptrace_scope），导致 gcore 失败，此时可能需要调整内核参数。

参考资料：