GDB切换调试线程时能否保证原线程执行不超指定行数？

所有结论基于scheduler-locking处于off模式、未手动冻结任何线程的默认调试场景。

问题1：第二个断点触发暂停时，是否可保证第一个线程的执行行数不超过3行？ #

不能保证。
输入next 3/step 3这类带步数的单步命令时，GDB的内部逻辑只是在当前操作的目标线程上，计算出当前位置往后数3行源码对应的内存地址，打一个一次性临时断点，随后直接恢复整个进程的运行，不会对目标线程加任何“最多跑3行”的强制限制。
程序恢复运行后，线程调度完全由操作系统内核控制，GDB不会介入调度逻辑，只有任意线程触发断点、信号这类调试事件时，GDB才会暂停整个进程拿回控制权。这期间目标线程能跑多少行完全由操作系统调度决定，没有上限约束。

问题2：是否存在“第一个线程执行2行后切换到第二个线程，随后第一个线程又额外执行1000余行，才因第二个线程的断点命中暂停”的可能？ #

这种情况完全可能发生，属于该模式下的典型非预期行为。
整个触发流程完全符合GDB和操作系统的运行逻辑：

• 在线程A的断点处输入next 3后，GDB打好对应临时断点就会放开所有线程运行
• 操作系统最先调度线程A执行，跑完2行源码后，线程A的CPU时间片耗尽，内核切换上下文去跑线程B
• 此时线程A既没碰到GDB设的第3行临时断点，也没触发任何其他调试事件，始终处于可运行状态。只要内核后续再次给线程A分配CPU时间片，它就会持续往下执行，跑几百上千行都有可能——这段时间里GDB根本没有介入程序运行，不会中途暂停线程A计数行数
• 直到线程B跑到预先设置的断点位置，触发调试信号通知GDB，GDB才会暂停整个进程。此时再查看线程A的执行位置，早就超过了原本预期的3行位置，多跑上千行完全是正常现象。

补充说明 #

如果需要保证单步命令严格控制当前线程的执行步数，不会出现其他线程抢跑、当前线程超跑的问题，需要调整scheduler-locking配置：

• set scheduler-locking on：程序恢复运行时仅执行当前选中线程，其余线程全部冻结
• set scheduler-locking step：仅在执行next/step等单步类命令时冻结其他线程，执行continue等全局继续命令时放开所有线程，是多线程调试单步场景的常用配置

内容的提问来源于stack exchange，提问作者ledonter