Linux下C++程序多线程卡死怎么抓取Dump-C++-PHP中文网

多线程死锁不会自动生成core dump，需用sigquit（ctrl+\或kill -3）主动触发；sigint（ctrl+c）和sigkill（kill -9）不生成dump；ulimit -c unlimited和core_pattern配置必须提前设置且生效。

linux下c++程序多线程卡死怎么抓取dump

多线程卡死（死锁）不会自动生成 core dump，必须主动触发 —— 用 SIGQUIT（Ctrl+\ 或 kill -3）才能生成可用的 dump 文件。

为什么 `Ctrl+C` 和 `kill -9` 抓不到 dump？

因为它们发送的是 SIGINT（默认终止进程）和 SIGKILL（强制终止，不可捕获），都不触发核心转储。只有 SIGQUIT（信号值 3）、SIGSEGV、SIGABRT 等少数信号在默认行为下会生成 dump。死锁程序仍在运行、未崩溃，所以得靠 SIGQUIT 主动“请它留个遗照”。

Ctrl+C → SIGINT → 进程退出，无 dump
Ctrl+\ → SIGQUIT → 进程终止 + 生成 core（前提是 ulimit -c unlimited 已生效）
kill -3 <pid></pid> 效果等同于 Ctrl+\，适合无法交互的后台进程

`ulimit -c unlimited` 必须提前设置，且只对当前 shell 生效

如果程序已启动再执行 ulimit，对已有进程无效。必须在启动前设置：

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

检查：运行 ulimit -c，输出不是 unlimited 或大于 0 就不行
临时生效：ulimit -c unlimited，然后在同一 shell 中运行你的程序
永久生效：在 /etc/profile 或用户 ~/.bashrc 里追加该行，再 source 或新开终端
注意：root 启动的服务需在 systemd service 文件中显式设置 LimitCORE=infinity，否则即使 shell 里设了也无效

dump 文件名和路径经常找不到？改 `core_pattern` 是刚需

默认 core 文件生成在程序运行目录，但权限不足、磁盘满、或程序 chdir() 后，就可能“生成了却看不见”。直接写死路径最稳：

临时设置（需 root）：echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern
%e 是程序名，%p 是 pid，%t 是时间戳，组合起来不重名、易定位
确保 /tmp 可写且空间足够（死锁 dump 包含所有线程栈，可能几十 MB）
验证是否生效：cat /proc/sys/kernel/core_pattern

用 `gdb` 加载 dump 后，第一件事不是 `bt`，而是 `info threads`

死锁的关键线索藏在线程状态里，不是单个栈帧：

启动：gdb ./your_program /tmp/core.your_program.12345
先执行 info threads：看哪些线程处于 Blocked 或长时间停在 pthread_mutex_lock / __lll_lock_wait
再用 thread apply all bt 查每个线程的完整调用栈，重点比对谁持有了哪把锁、谁在等哪把锁
常见死锁模式：m1.lock() → sleep → m2.lock() 与 m2.lock() → m1.lock() 交叉等待，gdb 里一眼就能对上

真正麻烦的不是生成 dump，而是程序没挂、你不敢 kill —— 这时候得靠 gcore <pid></pid> 主动生成内存快照，但它抓不到锁持有关系；而 SIGQUIT 虽然能停住现场，但必须提前配好 core_pattern 和权限，漏掉任意一环，dump 就消失在某个不可写的目录里。