gcore 是 GDB 套件中的一个实用工具，用于在不停止或崩溃程序的情况下，为正在运行的进程生成内存快照（Core Dump）。这在调试线上“卡死”或难以复现的逻辑问题时非常高效。
在终端中直接运行，最简单的语法如下：
core.<PID> 的文件。| 参数 | 说明 | 示例 |
|---|---|---|
-o <filename> |
指定输出文件的前缀或完整名称。 | gcore -o my_dump 1234 |
-a |
转储所有内存映射（包括通常被排除的部分）。 | gcore -a 1234 |
-d <dir> |
指定运行 GDB 时使用的目录。 | gcore -d /tmp 1234 |
ps -ef | grep 程序名 或 pidof 程序名 找到目标进程 ID。gcore <PID>。此时进程会短暂暂停，待文件写入磁盘后恢复运行。gdb <可执行程序路径> <生成的core文件>
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）进程。
gcore 的执行速度非常快（主要是磁盘 I/O 时间）。3). 捕捉“中间状态”或内存泄漏
当你怀疑程序运行到某个阶段逻辑有问题，或者发现内存占用异常上升时：
4). 容错与“时光倒流”
在进行一些可能破坏程序状态的危险 GDB 操作（比如手动调用 call 改变变量值）之前，先执行 gcore：
总结：它和传统 Core Dump 的本质区别
root 权限或与目标进程相同的用户权限才能执行转储。ptrace 调用（如设置了 /proc/sys/kernel/yama/ptrace_scope），导致 gcore 失败，此时可能需要调整内核参数。参考资料：
[0] gdb调试线程
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。