默认情况下gdb attach后只显示运行中线程，需用info threads查看所有已捕获线程；死锁时thread apply all bt易卡住，应先set scheduler-locking on或逐个线程bt；定位mutex持有者需比对__owner与info threads的LWP列；std::mutex调试建议断点在pthread_mutex_lock。
gdb attach到运行中的多线程进程后看不到所有线程？
默认情况下，gdb attach 后只显示当前正在运行的线程（或主线程），其他线程可能处于休眠/阻塞状态而被忽略。这不是 bug，而是 gdb 的线程视图默认行为。
- 用
info threads查看所有已知线程——它会列出线程 ID、状态和栈顶函数，但前提是线程已被 gdb 捕获（通常 attach 后能识别大部分） - 如果某些线程没出现，尝试先发送
SIGSTOP给目标进程：kill -STOP <pid>，再 attach，可提高线程快照完整性 - 确保编译时加了
-g -O0（避免内联优化干扰栈回溯），且链接了libpthread（现代系统通常默认，但静态链接时需显式指定）
死锁时 thread apply all bt 为什么卡住或输出不全？
thread apply all bt 在死锁场景下可能卡在某个线程的符号解析或内存读取阶段，尤其当某线程正持有调试器需要访问的锁（如 libc 内部锁）时。
- 改用
thread apply all bt full前，先执行set scheduler-locking on，防止线程切换干扰调试器自身状态 - 更稳妥的做法是逐个检查可疑线程：
thread <n>切换后单独执行bt，避开全局命令的同步开销 - 注意：若某线程栈显示在
pthread_mutex_lock或__lll_lock_wait，且调用链中反复出现同一 mutex 地址（如0x7f...abcd），大概率是该锁被其他线程持有着没释放
如何定位哪个线程持有了导致死锁的互斥量？
Linux 下 pthread mutex 是用户态+内核态混合实现，gdb 无法直接读取 mutex 内部 owner 字段（尤其 futex-based mutex），但可通过间接线索推断。
- 对每个阻塞在线程的
pthread_mutex_lock调用，用frame <num>跳转到其上层调用帧，查看传入的mutex参数地址（例如mov rdi, QWORD PTR [rbp-8]对应的变量） - 用
print *(pthread_mutex_t*)0x7f...尝试打印 mutex 结构——多数情况下字段不可读，但若看到__data.__owner == 12345（非零值），12345 就是持有该锁的线程 tid（注意：这是内核线程 ID，不是 gdb 的线程号） - 用
info threads输出中的 LWP 列（轻量级进程 ID）与__owner对比；匹配上即找到持有者，再thread find <lwp_id>定位 gdb 线程号
使用 std::mutex 时 gdb 显示不清晰怎么办？
std::mutex 底层仍调用 pthread，但 gdb 默认不展开 C++ 标准库封装，bt 可能只显示 std::mutex::lock() 而不透出内部 pthread 调用。
立即学习“C++免费学习笔记（深入）”；
- 编译时启用
-D_GLIBCXX_DEBUG（仅开发期）能让部分标准库函数输出更详细的调试信息，但会显著降低性能 - 更实用的是设置断点在底层：
break __pthread_mutex_lock或break pthread_mutex_lock，而非std::mutex::lock - 若使用
std::unique_lock或 RAII，注意析构函数中 unlock 可能被优化掉；加volatile临时变量或asm volatile ("" ::: "memory")防止优化干扰观察
bt 不够，得人工对照每个线程的 mutex 地址和 owner 字段交叉验证——没有自动工具能 100% 可靠判断，必须结合代码逻辑读。 
