根本解法是启用 set scheduler-locking on 以冻结其他线程，配合 next 单步、thread 命令锁定目标线程；禁用 non-stop 模式，优先使用条件断点过滤线程，并确保 -g -O0 编译及完整调试符号。
线程频繁切换导致断点命中混乱
当程序中线程创建密集、休眠短（如 sleep(1) 或空循环），GDB 默认会在线程间快速调度，你刚切到线程 2，它就退出了；刚在 thread_function 下断点，结果主线程 pthread_join 先抢到控制权——这不是 GDB 失效，而是它默认“让所有线程自由运行”，调试焦点被系统调度器劫持。
根本解法是关闭线程自动调度，强制 GDB 按需控制执行流：
- 启动后立即执行
set scheduler-locking on：暂停时仅当前线程可继续运行，其他线程冻结 - 若需单步但不进入函数内部（避免意外跳进其他线程的 syscall），用
next而非step；step可能触发线程切换，尤其在pthread_create或printf等 libc 调用中 - 配合
info threads确认当前线程 ID（如2），再用thread 2显式锁定，避免误操作切回主线程
为什么 set non-stop on 反而让问题更糟
有人听说“non-stop 模式支持多线程并发调试”，就启用 set non-stop on，结果发现断点全乱了——因为该模式下，GDB 不再阻塞所有线程，而是允许每个线程独立暂停/恢复。一旦某个线程在断点处停住，其他线程仍在跑，info threads 列表可能瞬间刷新多次，你看到的“当前线程”其实是上一帧快照。
真实建议是：
- 绝大多数竞态调试场景，**禁用**
non-stop（默认就是 off） - 只在需要观察多个线程**并行推进**行为（比如验证两个线程是否真的同时读写某变量）时才开，且必须搭配
thread apply all bt实时抓栈，不能依赖单一线程视图 - 开启后务必同步设
set print thread-events off，否则每次线程启停都会刷屏干扰判断
条件断点 + 线程过滤才是精准捕获的关键
频繁切换的本质是“太多线程在干相似的事”，与其手动切来切去，不如让 GDB 自动过滤目标线程。例如，在 thread_function 中只对线程 ID 为 2 的实例下断：
break thread_function if *(int*)arg == 2
注意这里依赖 arg 是传入的 thread_ids[i] 地址，实际需根据变量生命周期调整（如改为 id == 2 若已提升为局部变量）。更稳妥的做法是结合线程名：
- 编译时加
-g，并在代码中调用pthread_setname_np(pthread_self(), "worker-2") - 然后用
break thread_function if $_thread == 2（GDB 10.2+ 支持）或break thread_function if $rdi == 2（x86_64 下第一个参数常在%rdi） - 避免在
printf行设断点——它可能被不同线程反复触发，改设在逻辑分界点，如循环末尾if (i >= 5) break;前
容易被忽略的编译与符号陷阱
即使命令全对，仍可能“切不到线程”或“看不到变量”，常见原因不是 GDB 问题，而是构建环节缺失：
- 必须用
gcc -g -O0编译，-O2会让线程局部变量被优化进寄存器，print id直接报No symbol "id" in current context - 链接 pthread 时别漏
-lpthread，否则pthread_create符号缺失，info threads可能只显示主线程 - 若调试的是 release 构建产物，确认
readelf -S ./a.out | grep debug输出含.debug_*段，否则 GDB 无法映射源码行
最隐蔽的坑：某些发行版（如 Ubuntu 22.04）默认安装的 GDB 不带 Python 支持，thread apply all bt 会卡住或输出不全——运行 gdb --version 看是否含 python 字样，没有就重装 gdb-python3 包。
