死锁本身不会自动触发core dump，因其进程未崩溃、未退出、未收到信号；但可通过watchdog脚本定期检测线程阻塞状态（如pthread_mutex_lock、futex_wait），连续多次异常后调用gcore生成快照，或手动发送SIGQUIT（kill -3）触发默认core生成。
死锁本身不会自动触发 core dump，因为进程没崩溃、没收到信号、也没退出——它只是卡在 pthread_mutex_lock 或 sem_wait 上，状态仍是 S（可中断睡眠）或 R（运行中自旋），内核不会生成 core。但你可以用“主动快照 + 定时探测”组合实现准自动化抓取。
怎么让挂死进程自己吐出 core 文件
Linux 下没有原生“死锁触发 dump”机制，但可通过外部 watchdog 脚本定期检查线程状态，发现疑似死锁后调用 gcore：
- 用
ps -o pid,lwp,nlwp,stat,wchan -p <pid>查看线程状态：多个线程长期停在pthread_mutex_lock、__lll_lock_wait或futex_wait就高度可疑 - 配合
cat /proc/<pid>/stack快速确认所有线程当前函数调用链（无需 gdb 启动） - 脚本检测到连续 3 次采样都满足「>2 个线程阻塞在锁原语上」，就执行
gcore -o /tmp/core.hang.<pid> <pid> - 注意：该进程不能被
ptrace限制（如已被strace或其他调试器 attach），否则gcore会失败
为什么不能靠 ulimit -c unlimited 自动生效
ulimit -c unlimited 只对「异常终止」有效，而死锁不触发任何信号——SIGABRT、SIGQUIT 都得你手动发，SIGKILL（kill -9）则直接销毁现场，不留 core。
-
kill -3 <pid>（SIGQUIT）是较安全的选择：多数程序未捕获它，会触发默认行为（打印堆栈 + 生成 core） - 但某些程序（尤其用了
signal(SIGQUIT, SIG_IGN)）会忽略，此时需改用gcore - 不要依赖
core_pattern的通配规则自动捕获死锁场景——它只响应进程 exit/abort，不响应 hang
gdb 分析时最容易忽略的三个点
拿到 /tmp/core.hang.<pid> 后，gdb ./your_program /tmp/core.hang.<pid> 进去，关键不是看哪个线程“报错”，而是交叉验证锁持有关系：
立即学习“C++免费学习笔记（深入）”；
-
info threads输出里标为running的线程未必真在跑——可能卡在 tight loop 里，用thread <n>; info registers看rip是否反复指向同一条指令 -
info mutex在 GDB ≥8.0 可用，但仅对未被编译器优化掉的pthread_mutex_t变量有效；若用的是std::mutex且带-O2，基本看不到 owner 字段 - 别只看
bt最顶上一层：死锁常发生在嵌套调用中，比如foo() → bar() → std::mutex::lock()，要展开多层才能定位到真正持锁/等锁的函数位置
真正难的不是生成 dump，而是从一堆看似正常的线程状态里识别出“静止中的循环等待”。gcore 是工具，info threads 和 info mutex 是线索，但最终需要你对照源码，手工画出锁依赖图——这点没法自动化。
