多线程调试的困惑

不少人在调试多线程程序时，遇到过各种各样看似奇怪的问题。比如，本来很容易复现的问题，调试时却莫名其妙的消失了；或者，本来可以正常运行的程序，调试时却总是异常退出。

究其原因，是因为程序的正常执行逻辑在调试的过程中受到了干扰。调试时我们可能需要经常设置断点，查看变量、内存、寄存器等状态信息，这会导致多个线程间的时序逻辑受到干扰。

有人会说，我不用调试器，就用printf。然而，即便是最简单的printf，也可能会对程序逻辑产生很大的影响。不过这不是本文重点，不再展开，后续会有专门文章来分析，感兴趣的可以右上角关注一下！

GDB作为调试神器，为我们提供了很多专门针对多线程调试的工具和方法，本文会以实例的形式，逐一详细讲解！

示例代码

本文以下面这个程序为例，详细介绍GDB调试多线程代码的方法：

GDB提供了多个针对多线程程序的调试命令。

查看线程状态信息

info threads 命令可以查询被调试程序中的线程的信息。

使用GDB调试程序时，每个线程至少有三个ID：

Pthread库为线程分配的pthread ID，也就是用pthread_self()返回的IDLinux kernel为线程分配的thread ID，也就是gettid()返回的IDGDB为线程分配的ID。执行GDB调试命令时要指定的线程ID，如无特殊说明，都是指的这个ID

如：

info threads显示，当前共有三个线程。以主线程（第一行）为例：1是GDB为主线程分配的ID，接下来0x7ffff7da3740是pthread库为主线程分配的pthread ID，后面括号中的355298是kernel为主线程分配的thread ID，再后面是该线程被中断时，代码正在执行的代码位置。

可以通过ps命令或者proc文件系统查看确认：

root@ubuntu:~# ps -eT | grep test 355298  355298 pts/9    00:00:02 test 355298  355301 pts/9    00:00:02 test 355298  355302 pts/9    00:00:02 testroot@ubuntu:~# root@ubuntu:~# ls /proc/355298/task/355298  355301  355302

线程1前面有个星号*，表示当前线程。默认情况下，执行的GDB命令是针对当前线程。比如此时执行bt(backtrace)命令，获取的是线程1的调用栈:

切换当前线程

thread <thread-id>命令可以切换当前线程，如thread 2把线程2切换为当前线程：

此时用info threads查看，星号*已经切到了线程2的前面。

针对指定线程执行命令

thread apply [thread-id-list | all] command 可以针对指定线程执行命令

如：

thread apply all bt：打印所有线程的调用栈信息thread apply 3 bt：打印线程3的调用栈信息thread apply 2-3 bt：打印线程2和线程3的调用栈信息针对特定线程设置断点

在设置断点时，我们可以选择让断点对所有的线程生效，或只对特定线程生效。命令格式为：

break <location>  # 在<location>设置断点，并对所有线程生效break <location> thread <thread-id> # 在<location>设置断点，仅对<thread-id>指定的线程生效break <location> thread <thread-id> if <condition> # 在<location>设置条件断点断点，仅对<thread-id>指定的线程生效

比如 break do_stuff thread 2, 这个命令在do_stuff()入口设置断点，只有thread 2调用这个函数是才会触发断点，其他thread调用这个函数不会触发断点。

GDB中的其他所有类型的断点，也支持对特定线程设置断点，如tbreak、watch等。

断点相关的东西，相对比较简单，不再单独演示。

控制线程创建和退出信息set print thread-events on/off 设置是否打印线程创建和退出信息，如上面例子中的：

[New Thread 0x7ffff7da2700 (LWP 355301)][New Thread 0x7ffff75a1700 (LWP 355302)]

有时候使用thread apply [thread-id-list | all] command会稍显繁琐，GDB贴心的为我们提供了几种命令缩写：

taas command 相当于 thread apply all -s commandtfaas command 相当于 thread apply all -s -- frame apply all -s command 

tfaas这个命令非常有用。比如，有时我们只记得一个变量或参数的名字，却忘了或不知道它是在哪个具体的函数中，就可以用这个命令：tfaas p var_name，这个命令会搜索所有线程的调用栈，找到名字为var_name的变量，并打印它的值，如：

(gdb) tfaas p x1Thread 2 (Thread 0x7ffff7da2700 (LWP 370514) "test"):#0  thread_1 (arg=0x0) at test.c:10$5 = 432504243(gdb) tfaas p y2Thread 3 (Thread 0x7ffff75a1700 (LWP 370515) "test"):#0  thread_2 (arg=0x0) at test.c:18$6 = 428735002(gdb)

为了更好的调试多线程程序，GDB提供了两种模式来控制程序的执行：

All-Stop Mode：在该模式下，不管因为什么原因，一个线程被中断执行，其他所有的线程都会同时被中断执行。Non-Stop Mode：在该模式下，一个线程被中断执行，不会影响其他线程的正常执行。

接下来，我们详细讲解一下这两种模式的区别和用法。

All-Stop mode

在GDB中调试多线程程序，默认处于All-Stop Mode，即只要有一个线程被中断执行，其他所有的线程都会被中断执行。

比如，程序在运行时，按Ctrl+C，所有的线程都会被中断执行，同样的，当恢复程序执行时，所有的线程都会同时恢复执行。比如执行continue、step、next等命令。

也就是说，在All-Stop模式下，只要有一个线程由于触发断点等原因停止执行，整个进程都会被停下来，这在一定程度上可以保证所有线程状态的同步，保持数据的一致性。比如，在查看某个可能会被多个线程修改的数据时，不需要担心在查看的同时被其他线程修改掉。

但是，这也给程序调试带来了一些困难，比如，无法100%精确地进行单步调试。有时你会发现，在执行step命令之后，程序却停在了另外一个线程中。

在线程2和线程3都会调用do_stuff()，在do_stuff()设置断点后，线程2先触发断点停在第4行，同时当前线程切换为线程2，然后执行step命令单步执行一条语句，

理论上讲，线程2执行一条语句应该停在第5行代码，然而实际上却是执行完step命令后，线程3触发了断点，而此时线程3并未按照step命令的预期执行一行代码，而是仍然停留在第4行。

再次单步执行，线程2却再次触发了断点，说明线程2执行了不止一条语句（思考题：这是为什么呢？）！

为了解决这个问题，GDB提供了set scheduler-locking mode命令，锁定当前线程。（思考题：针对这个特定案例，还有其他方法吗？）

线程锁定模式

set scheduler-locking mode

mode 可能是：

off：不锁定任何线程，当恢复程序执行时，所有线程都可以自由执行on：锁定当前线程，执行continue、step、next、finish等命令时，只有当前线程恢复执行，其余线程仍然处于中断状态step：当单步执行时，和on一样，其余情况和off一样。简单来说，就是在这个锁定模式下执行单步操作，只有当前线程会执行，其他线程仍然处于中断状态。而执行其他命令时，如continue、finish等，和off一样，即所有线程都可以自由执行。replay：在反向调试时和on一样，其余情况下，和off一样。对反向调试不了解的童鞋可以参考《详解GDB高级技巧—反向调试，以上帝视角观察程序执行轨迹》。

默认是replay模式，可以通过show scheduler-locking查看当前锁定模式。

我们演示一下：

简单解释一下：

先在do_stuff()设置断点，并执行continue恢复程序执行。随后，线程2触发断点，停在第4行代代码。此时程序的状态是：线程2由于触发断点，停在第4行；由于在All-Stop模式，所以线程3也被中断，恰巧也停在第4行然后执行set scheduler-locking on 锁定当前线程2。此时单步执行，线程2停在第5行，而线程3仍然停在第4行。再执行continue，线程2会再次触发断点，此时发现线程3仍然停在第4行。

可见，执行set scheduler-locking on开启锁定模式之后，无论用什么命令恢复程序执行，只有当前线程2会执行，其余线程一直处于中断状态。

不过，同时中断所有的线程，可能会导致有些程序无法正常运行。比如，有些程序需要有专门的线程实时处理外部的消息或事件等，如果把所有的线程都中断的话，会由于外部事件得不到及时响应而导致程序异常终止。

这时，就需要用到Non-Stop模式

Non-Stop Mode

在Non-Stop模式下，一个线程被中断执行，并不会影响到其他线程。比如，一个线程触发断点，只有这一个线程会被中断执行，其余线程不受影响继续执行。同样的，在程序运行时，执行Ctrl+C，也只会中断一个线程。

要开启Non-Stop模式，需要在程序开始运行前，执行下面两个命令：

set pagination offset non-stop on

可以通过下面这个命令关闭Non-Stop模式，即进入All-Stop模式

set non-stop off

查看Non-Stop模式是否开启：

show non-stop

重新在GDB中加载测试程序，在开始运行之前，执行set non-stop on命令开启Non-Stop模式：

执行run(r)命令开始运行程序，然后Ctrl+C中断执行，并用info threads命令查看所有线程状态：

可见，在Non-Stop模式下，Ctrl+C只中断了线程1，线程2和3并未受到影响，仍处于运行状态。因此，此时无法通过bt命令获取线程2和线程3的调用栈：

interrupt -a命令可以中断所有线程的执行，有时候这是非常必要的：

continue -a命令可以恢复所有线程的执行：

后台执行

我们知道，在Shell中执行程序时，后面加一个&符号，可以把程序放在后台执行。在GDB中你同样可以在命令后面加一个&符号，这样就能把命令放在后台执行。

之所以提供后台执行的模式，其实就是让GDB始终可以接收用户输入，即便被调试程序正常运行时，仍然可以在GDB中执行命令。这在Non-Stop模式下，有时会非常有用。

前面讲过，Non-Stop模式下，按Ctrl+C只会中断那个接收到SIGINT信号的线程，其他线程不会受到影响继续运行。但是，有时候，为了尽量保证线程状态的同步，我们可能想要让所有的线程同时被中断或同时恢复运行，这种情况下，就可以通过后台执行命令的方式来实现。

并不是所有的命令都支持后台执行，目前支持后台执行的命令有：continue、run、attach、step、stepi、next、nexti、finish、until

系统调用的处理

我们知道，在执行系统调用的时候，如read(), write(), select()等，如果收到信号，这些系统调用会异常返回，errno会被赋值为EINTR。

一般来说，程序中需要判断系统调用的返回值和errno来对这种情况进行适当的处理，比如重试一次。不过，有些实现不太规范的程序可能不会对这种情况进行判断和处理。

因此在用GDB调试这类程序的时候，可能会发现程序的执行逻辑发生了很大的变化。这是因为，使用GDB进行调试时，我们经常需要中断一个或多个线程的执行来观察当前程序的运行状态，如变量、内存数据、寄存器等，而这有可能会导致一些系统调用异常返回，从而给人产生某种错觉，似乎程序正常执行时的逻辑和在GDB中执行时的逻辑有很大的差异。

不过，这也算是提前暴露了程序中隐藏的问题，从这个角度讲，也是一件好事！

多线程调试命令小结

- info threads：查看线程状态信息- thread <thread-id>：切换当前线程- thread apply [thread-id-list | all] <command>：针对指定线程执行命令- break <location> thread <thread-id> if <condition>：设置条件断点，仅对指定线程生效- set scheduler-locking on/off/step/replay：控制是否锁定当前线程，如果当前程序被锁定，恢复程序运行时，只有当前线程可以运行- set non-stop on：开启Non-Stop模式，该模式下，一个线程被中断执行，不会影响其他线程- set non-stop off：关闭Non-Stop模式，即进入All-Stop模式。该模式下，一个线程被中断执行，其他所有线程都会被中断- interrut -a：中断所有线程执行- command &：后台执行

本文是高级调试技术系列专题第十篇，有任何意见和建议欢迎留言！

如有遗漏，欢迎留言补充！如果觉得有用，别忘了点赞，关注！