使用 GDB 调试多进程程序

GDB 是 linux 系统上常用的 c/c++ 调试工具，功能十分强大。对于较为复杂的系统，比如多进程系统，如何使用 GDB 调试呢？考虑下面这个三进程系统：

进程


Proc2 是 Proc1 的子进程，Proc3 又是 Proc2 的子进程。如何使用 GDB 调试 proc2 或者 proc3 呢？
实际上，GDB 没有对多进程程序调试提供直接支持。例如，使用GDB调试某个进程，如果该进程fork了子进程，GDB会继续调试该进程，子进程会不受干扰地运行下去。如果你事先在子进程代码里设定了断点，子进程会收到SIGTRAP信号并终止。那么该如何调试子进程呢？其实我们可以利用GDB的特点或者其他一些辅助手段来达到目的。此外，GDB 也在较新内核上加入一些多进程调试支持。
接下来我们详细介绍几种方法，分别是 follow-fork-mode 方法，attach 子进程方法和 GDB wrapper 方法。

follow-fork-mode

在2.5.60版Linux内核及以后，GDB对使用fork/vfork创建子进程的程序提供了follow-fork-mode选项来支持多进程调试。
follow-fork-mode的用法为：
set follow-fork-mode [parent|child]

• parent: fork之后继续调试父进程，子进程不受影响。
• child: fork之后调试子进程，父进程不受影响。
  

因此如果需要调试子进程，在启动gdb后：

(gdb) set follow-fork-mode child

并在子进程代码设置断点。
此外还有detach-on-fork参数，指示GDB在fork之后是否断开（detach）某个进程的调试，或者都交由GDB控制：
set detach-on-fork [on|off]

• on: 断开调试follow-fork-mode指定的进程。
• off: gdb将控制父进程和子进程。follow-fork-mode指定的进程将被调试，另一个进程置于暂停（suspended）状态。
  

注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。
follow-fork-mode/detach-on-fork的使用还是比较简单的，但由于其系统内核/gdb版本限制，我们只能在符合要求的系统上才能使用。而且，由于follow-fork-mode的调试必然是从父进程开始的，对于fork多次，以至于出现孙进程或曾孙进程的系统，例如上图3进程系统，调试起来并不方便。

Attach子进程

众所周知，GDB有附着（attach）到正在运行的进程的功能，即attach 命令。因此我们可以利用该命令attach到子进程然后进行调试。
例如我们要调试某个进程RIM_Oracle_Agent.9i，首先得到该进程的pid

[root@tivf09 tianq]# ps -ef|grep RIM_Oracle_Agent.9i  nobody    6722  6721  0 05:57 ?        00:00:00 RIM_Oracle_Agent.9i  root      7541 27816  0 06:10 pts/3    00:00:00 grep -i rim_oracle_agent.9i

通过pstree可以看到，这是一个三进程系统，oserv是RIM_Oracle_prog的父进程，RIM_Oracle_prog又是RIM_Oracle_Agent.9i的父进程。

[root@tivf09 root]# pstree -H 6722

通过 pstree 察看进程


启动GDB，attach到该进程

用 GDB 连接进程
 

GDB wrapper

很多时候，父进程 fork 出子进程，子进程会紧接着调用 exec族函数来执行新的代码。对于这种情况，我们也可以使用gdb wrapper 方法。它的优点是不用添加额外代码。
其基本原理是以gdb调用待执行代码作为一个新的整体来被exec函数执行，使得待执行代码始终处于gdb的控制中，这样我们自然能够调试该子进程代码。
还是上面那个例子，RIM_Oracle_prog fork出子进程后将紧接着执行RIM_Oracle_Agent.9i的二进制代码文件。我们将该文件重命名为RIM_Oracle_Agent.9i.binary，并新建一个名为RIM_Oracle_Agent.9i的shell脚本文件，其内容如下：
[root@tivf09 bin]# mv RIM_Oracle_Agent.9i RIM_Oracle_Agent.9i.binary  [root@tivf09 bin]# cat RIM_Oracle_Agent.9i  #!/bin/sh  gdb RIM_Oracle_Agent.binary

当fork的子进程执行名为RIM_Oracle_Agent.9i的文件时，gdb会被首先启动，使得要调试的代码处于gdb控制之下。
新的问题来了。子进程是在gdb的控制下了，但还是不能调试：如何与gdb交互呢？我们必须以某种方式启动gdb，以便能在某个窗口/终端与gdb交互。具体来说，可以使用xterm生成这个窗口。
xterm是X window系统下的模拟终端程序。比如我们在Linux桌面环境GNOME中敲入xterm命令：

现在就可以调试了。一个新的问题是，子进程一直在运行，attach上去后都不知道运行到哪里了。有没有办法解决呢？
一个办法是，在要调试的子进程初始代码中，比如main函数开始处，加入一段特殊代码，使子进程在某个条件成立时便循环睡眠等待，attach到进程后在该代码段后设上断点，再把成立的条件取消，使代码可以继续执行下去。
至于这段代码所采用的条件，看你的偏好了。比如我们可以检查一个指定的环境变量的值，或者检查一个特定的文件存不存在。以文件为例，其形式可以如下：
void debug_wait(char *tag_file)  {      while(1)      {          if (tag_file存在)              睡眠一段时间;          else              break;      }  }

当attach到进程后，在该段代码之后设上断点，再把该文件删除就OK了。当然你也可以采用其他的条件或形式，只要这个条件可以设置/检测即可。
Attach进程方法还是很方便的，它能够应付各种各样复杂的进程系统，比如孙子/曾孙进程，比如守护进程（daemon process），唯一需要的就是加入一小段代码。

Gdb调试多进程程序

程序经常使用fork/exec创建多进程程序。多进程程序有自己独立的地址空间，这是多进程调试首要注意的地方。Gdb功能强大，对调试多线程提供很多支持。

方法1：调试多进程最土的办法：attach pid

Attach是调试进程的常用办法，只要有可执行程序以及相应PID，即可工作。当然，为方便调试，可以在进程启动后，设定sleep一段时间，如30s，这样即可有充足的时间来attach。

方法2： set follow-fork-mode child + main断点

当设置set follow-fork-mode child，gdb将在fork之后直接执行子进程，知道碰到断点后停止。如何设置子进程的断点呢？在父进程中是无法知道子进程的地址空间的(只有等程序载入后方可知)。Gdb提供一个很方便的机制：main函数的断点将被子进程继承(毕竟main是任何程序的入口)。

注意：程序在main停下后，可尝试设置断点。断点是否有效，取决于gdb是否已经载入目标程序的地址空间。

方法3： set follow-fork-mode child + catch exec

Cache点是一种特殊的breakpoint。Gdb能够catch的事件很多，如throw/catch/exception/syscall/exec/fork/vfork等。其中和多进程关系最大的就是exec/fork事件。

举例：

GNU gdb Fedora (6.8-27.el5)

Copyright (C) 2008 Free Software Foundation, Inc.

(gdb) catch exec

Catchpoint 1 (exec)

(gdb) set follow-fork-mode child

(gdb) r  -d ***

Catchpoint 1 (exec'd /****/binary), 0x0000003c68800a70 in _start ()

   from /lib64/ld-linux-x86-64.so.2

(gdb) bt

#0  0x0000003c68800a70 in _start () from /lib64/ld-linux-x86-64.so.2

#1  0x0000000000000003 in ?? ()

#2  0x00007fff65c6e85a in ?? ()

#3  0x00007fff65c6e85d in ?? ()

#4  0x00007fff65c6e860 in ?? ()

(gdb) b lib.cc:8720

No symbol table is loaded.  Use the "file" command.

(gdb) c

Continuing

(gdb) bt

#0  0x0000003c68800a70 in _start () from /lib64/ld-linux-x86-64.so.2

#1  0x0000000000000002 in ?? ()

#2  0x00007fff1af7682a in ?? ()

#3  0x0000000000000000 in ?? ()

(gdb)  b lib.cc:8720

Breakpoint 2 at 0x15f9694: file lib.cc, line 8720.

(gdb) c

Continuing.

[Thread debugging using libthread_db enabled]

[Thread 0x40861940 (LWP 12602) exited]

[Switching to process 12630]

0x0000003c6980d81c in vfork () from /lib64/libpthread.so.0

Warning:

Cannot insert breakpoint 2.

Error accessing memory address 0x15f9694: Input/output error.

(gdb) bt

#0  0x0000003c6980d81c in vfork () from /lib64/libpthread.so.0

#1  0x000000000040c3fb in ?? ()

#2  0x00002adeab604000 in ?? ()

#3  0x01000000004051ef in ?? ()

#4  0x00007fffff4a42f0 in ?? ()

#5  0x686365746e6f6972 in ?? ()

#6  0x0000000d0000000c in ?? ()

#7  0x0000000b0000000a in ?? ()

#8  0x0000000000000000 in ?? ()

(gdb) delete 2  --此处当breakpoint无效时，必须删除，否则程序无法继续

(gdb) c

Continuing.

[New process 12630]

Executing new program: /****/binary

warning: Cannot initialize thread debugging library: generic error

[Switching to process 12630]

 

Catchpoint 1 (exec'd /****/binary), 0x0000003c68800a70 in _start ()

   from /lib64/ld-linux-x86-64.so.2

(gdb) bt

#0  0x0000003c68800a70 in _start () from /lib64/ld-linux-x86-64.so.2

#1  0x0000000000000009 in ?? ()

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

(gdb) b lib.cc:8720

Breakpoint 4 at 0x15f9694: file lib.cc, line 8720.

(gdb) b type.cc:32

Breakpoint 5 at 0x1693050: file type.cc, line 32.

(gdb) c

Continuing.

(gdb)  -- 和正常程序调试一样

说明：catch exec后，程序将在fork/vfork/exec处停下。并非每次停下后，设置断点都是有效的。如提供断点无效，需要删除，否则程序无法继续。要能够在新进程中设置断点，一定要等到新进程的地址空间被载入后，设置断点是才有效(exec将改变原程序的地址空间)。上述例子，主要想展示如何对新进程设置断点！

注意： 1)程序地址非常重要(代码和数据地址一样重要)。使用gdb时，多多注意和利用地址信息。 2)On some systems, when a child process is spawned by vfork, you cannot debug the child or parent until an exec call completes.

方法4：info inferiors/inferiors inferiors

设置set detach-on-fork off/set follow-exec-mode new。

If you choose to set `detach-on-fork' mode off, then gdb will retain control of all forked processes (including nested forks). You can list the forked processes under the control of gdb by using the info inferiors command, and switch from one fork to another by using the inferior command.

所使用的gdb不支持set detach-on-fork off/set follow-exec-mode new/info inferiors。不清楚。

参考: 4.11 Debugging Forks