GDB默认不锁定线程调度，导致next/step可能跳转到其他线程；应先用info threads确认当前线程，再执行set scheduler-locking on锁定，避免变量错乱和调试失控。
默认情况下，GDB 不会锁定线程调度，单步或 continue 时其他线程可能随时抢占执行，导致断点停在意外位置、变量值错乱、甚至调试流完全失控。
为什么 next/step 会跳到别的线程里
当你在某个线程（比如 thread 2）中执行 next 或 step，GDB 默认只控制当前线程的单步行为，但内核调度器仍可把 CPU 切给 thread 3 或 thread 4。结果就是：你按了 next，程序却停在另一个线程的某行——这不是 bug，是并发本质。
常见现象包括：
- 刚在
worker_thread()的第 15 行设好断点，continue后却停在main()的第 8 行 -
print local_var显示的是另一个线程的栈帧里的同名变量 - 反复
next却始终无法进入目标函数，因为每次都被别的线程“抢走”执行权
用 set scheduler-locking on 锁定当前线程
这是最直接有效的干预方式。启用后，GDB 会阻止其他线程在你单步或继续时被调度运行。
操作要点：
- 必须在切换到目标线程后立即设置：
thread 2→set scheduler-locking on -
on模式下：next/step/continue都只让当前线程推进，其余线程挂起 -
off是默认值，禁用锁定；step是折中模式（仅对step生效，next和continue仍不锁） - 退出前建议关掉：
set scheduler-locking off，否则后续调试其他线程会意外被锁住
配合 thread + info threads 精准锚定目标
光锁不够，得先确认你在调谁。多线程调试中，「当前线程」容易误判，尤其在断点触发后未手动切换时。
关键习惯：
- 每次断点命中后，第一件事是执行
info threads，看*在哪一行，确认当前线程 ID - 不要依赖记忆切换，用
thread N显式指定，例如：thread 3，而不是靠thread next猜 - 如果目标线程已退出，
thread 3会失败并报错Thread ID 3 not known，此时需重新run或检查程序逻辑 -
info threads输出中的LWP（轻量级进程 ID）可用于外部工具交叉验证，比如用pstack <pid>对照
别忽略编译和断点粒度的影响
干扰不止来自调度，还藏在符号信息和断点范围里。
实操注意点：
- 必须用
-g编译，否则info threads可能显示不全帧信息，thread切换后看不到源码上下文 - 避免在内联函数或优化代码（
-O2）中设断点——GDB 可能将断点映射到错误线程或跳过关键路径 - 线程专属断点更安全：
break process_data.c:42 thread 3比全局break process_data.c:42干扰小得多 - 条件断点慎用共享变量做条件，比如
break data.c:100 if counter > 10，多个线程都可能触发，反而加剧混乱
真正麻烦的不是命令记不住，而是忘记「当前线程是否被锁」「当前看到的变量到底属于谁」——这两点一旦出错，所有后续操作都在错的基础上叠加。调试前花三秒敲 info threads 和 set scheduler-locking on，比花十分钟猜为什么变量值不对划算得多。
