set scheduler-locking on 是最直接有效的办法，它强制只让当前线程执行、其余全部暂停，确保 step/next 严格单线程推进，但需配合 thread 切换和线程限定断点，并在调试后恢复 off 避免程序卡死。
set scheduler-locking on 是最直接有效的办法
默认情况下，step 或 next 时其他线程也会跑——这不是 bug，是 GDB 的全停止模型在「单步」动作里没生效。真正起作用的是 set scheduler-locking 命令，其中 on 模式能强制只让当前线程执行，其余全部暂停。
-
set scheduler-locking on后，每次step/next都严格只推进当前线程一行，其他线程完全冻结 - 该设置不影响断点命中逻辑：其他线程走到断点仍会中断，并把控制权交还给 GDB（此时当前线程可能已切换）
- 退出调试前建议恢复为
off，否则后续continue会卡住整个程序
为什么 set scheduler-locking step 不够用
step 模式看似更精细，但实际行为有陷阱：它只在单步时锁线程，一旦你敲 continue、finish 或 until，其他线程立刻恢复运行——而且如果它们中途撞上断点，GDB 会自动把那个线程设为当前线程，你原来专注的线程反而被晾在一边。
- 想稳住一个线程反复单步看变量变化？
step模式下容易“丢线程” -
on模式才是“盯死一个线程”的确定性选择 -
step模式适合快速过掉某段代码，同时又不希望其他线程完全静止太久的场景
配合 thread 切换和断点才能真正控住目标线程
光靠 set scheduler-locking on 还不够——你得先确认当前线程是你想调试的那个。GDB 启动后默认停在主线程，但多线程程序中真正出问题的常是 worker 线程。
- 用
info threads查所有线程 ID 和状态，注意 LWP 号（Linux 轻量级进程 ID） - 用
thread <ID>切到目标线程，再frame 0确保栈帧正确 - 断点要打在目标线程必经路径上，比如
break worker_loop.c:42 thread 3，避免所有线程都停 - 如果已停在错误线程，别急着
step，先thread 3切过去再锁
常见误操作：忘了关锁或切错线程
很多人调完几行就以为搞定，结果 continue 后程序没响应——大概率是还挂着 on 锁，而目标线程早已退出或阻塞，其他线程又被锁死，整个进程僵住。
- 每次
set scheduler-locking on后，最好记下当前线程 ID，调试完手动set scheduler-locking off - 用
info threads快速确认哪些线程处于running状态（说明锁没生效）或stopped（正常） - 如果发现多个线程同时停在同一个断点，说明断点没限定线程，赶紧
delete重打
真正难的不是命令本身，而是每次单步前都要确认三件事：我在哪个线程、这个线程是否真的在执行、其他线程是否被可靠地按住了——少查一次 info threads，就可能浪费十分钟在奇怪的竞态现象里。
