gdb调试多线程时默认只显示当前线程，需用info threads查看全部，thread ID切换，set follow-fork-mode控制子线程跟踪，避免在mutex::lock内设断点；core dump默认仅含崩溃线程，应改用gcore抓全量快照。
gdb 调试多线程时看不到所有线程？
默认 gdb 启动后只显示当前执行线程，其他线程可能处于休眠或阻塞状态，容易误判为“卡死”或“没跑起来”。关键不是线程没启动，而是 gdb 没主动展示。
- 用
info threads查看全部线程列表，每个线程有唯一 ID（如Thread 2 (LWP 12345)） - 用
thread 2切换到指定线程，再执行bt或print var查状态 - 加断点前先
set follow-fork-mode child（调试子线程）或set follow-fork-mode parent（调试主线程），否则 fork 或std::thread启动后 gdb 会跟丢 - 避免在
std::mutex::lock()内部设断点——可能触发 gdb 自身锁竞争，导致假死
Linux 下用 pthread 时 core dump 不包含线程上下文？
默认 ulimit -c 生成的 core 文件只保存崩溃线程的栈，其余线程状态丢失，难以复现竞态问题。
- 编译时加
-g -O0确保符号完整；运行前执行echo /proc/sys/kernel/core_pattern确认路径可写 - 用
echo '/tmp/core.%t.%p.%e' | sudo tee /proc/sys/kernel/core_pattern设置带时间戳和 PID 的命名，避免覆盖 - 加载 core 时用
gdb ./a.out /tmp/core.1712345678.12345.a.out，进 gdb 后立刻执行info threads——若只看到一个线程，说明 core 是单线程捕获的，需改用gcore主动抓全量快照 -
gcore -o /tmp/fullcore $(pidof a.out)可强制获取所有线程内存镜像，但要求进程仍在运行且未被 ptrace 限制
VS Code + C++ Extension 调试 std::thread 卡在 join()？
不是代码逻辑卡住，而是调试器对 std::thread 生命周期管理不透明，尤其在线程已结束但 joinable() 仍返回 true 时，join() 会阻塞或触发未定义行为。
- 在
join()前加断点，用print thrd.joinable()确认状态；若为 false，说明线程已被 move 或 detach，强行 join 会 terminate - VS Code 的
launch.json中确保"externalConsole": false，否则控制台输入可能干扰线程调度 - 避免在 lambda 捕获中持有局部对象引用（如
[&obj]{...}），线程运行时局部变量已析构，gdb 显示 - 启用
set scheduler-locking on（gdb）或 VS Code 的 “All Threads” 断点选项，防止单步时其他线程抢走 CPU 导致状态突变
Valgrind 报 Helgrind 错误但程序看似正常？
Helgrind 检测的是潜在竞态（data race），不是崩溃。它报告 Possible data race 并附上两个访问栈，哪怕你加了 mutex，也可能因锁粒度不对、漏锁、或 RAII 对象生命周期错位而漏检。
立即学习“C++免费学习笔记（深入）”；
- 运行命令必须是
valgrind --tool=helgrind --suppressions=/usr/lib/valgrind/helgrind.supp ./a.out，否则系统库调用（如std::cout）会刷屏误报 - 重点看 Helgrind 输出中的
Address 0x... is 8 bytes inside a block of size 16 alloc'd—— 定位到具体变量，再查谁读、谁写、是否同一把锁保护 - 常见陷阱：用
std::shared_ptr管理共享数据，但只同步了指针本身，没同步其指向的内容；或std::atomic_flag忘了.test_and_set()初始化 - Helgrind 无法检测逻辑错误（如死锁），需配合
--tool=drd或std::mutex构造时加调试标记（如自定义 wrapper 记录 lock/unlock 顺序）
std::this_thread::sleep_for 和条件变量混用时，gdb 的 next 可能跳过唤醒逻辑，得靠 watch 监视谓词变量变化。 
