nginx源码分析--使用GDB调试（strace、 pstack ）

http://blog.csdn.net/yusiguyuan/article/details/26981329

在学习优秀的源代码时是 少不了源码的跟踪与调试，它不仅是我们解决程序bug的有效途径 也是我们理解、学习优秀源码的有效途径。

本文主要介绍一些源码调试的方法，并结合Nginx 源码进行示例。

1， 利用GDB调试

   a，首先你应该熟悉 GDB 调试的一些基本命令（不熟悉的移步 至 用GDB调试程序 ,熟悉step，run，break，list，info，continue等命令)。

   b,  下载nginx 源码，这里使用nginx-1.0.14，解压文件。其中auto文件夹里包含了configure 运行时的各种命令集合，src是源码。为了利用

        GDB调试Nginx，需要在生成Nginx程序时把 -g 编译选项打开。我们需要修改  auto/cc/conf 文件 把 ngx_compile_opt="-c"  加上  -g 选项

         变为 ngx_compile_opt="-c -g"， 下一步执行configure命令： sudo ./configure  ，然后运行命令：vim  objs/Makefile  确认一下-g参数是

         否加上了。如下图。

           

         -g  编译选项已打开，然后执行命令: sudo make .(如果之前已经执行过make，那么第二次make时 需要 确保能够重新编译，此时可以通过

            刷新所有源文件时间戳，间接达到重新编译出一个新的Nginx可执行程序，命令为: find . -name "*.c" | xargs touch ), 好了，Nginx编译成功。

   c, 启动 nginx ,在objs目录下执行命令：sudo  ./nginx ,成功运行nginx后执行命令： ps -ef | grep nginx， 查看nginx的master及worker进程的PID，

        如果对nginx 工作进程 2177进行gdb调试，那么可以利用gdb的 -p 选项。 命令： gdb  -p 2177.

      当有多个工作进程时 调试起来比较麻烦。我们可以修改配置项，修改文件 nginx.conf 。加入master_process  off;  单进程模式 将监控进程和

      工作 进程逻辑全部合在一个 进程里。    此时只有一个进程，可以方便的利用gdb进行调试。

     我们知道工作进程会停留在epoll_wait处等待相应的事件发生，而这个函数调用被封装在ngx_process_events_and_timers 中。于是我们在

     这个函数设置一个断点： b ngx_event.c:ngx_process_events_and_timers ，结合gdb 命令c ,s,n  如图所示：

    

   采用命令c，使得nginx一直运行，直到遇到第一个断点,处理事件的方法是ngx_process_events，于是我们用命令 s 跟踪进去这个函数 .当执行到

   epoll_wait函数的时候，发现进程停留在这里，不能在向下执行。这就证明了 worker子进程阻塞在epoll_wait函数调用处。此时我们在另一个终端

   执行下列命令，以向nginx发送消息： curl -I localhost . 可以看到请求已经发送，正在等待回应。

   此时继续执行命令 c  即可在另一终端得到 回应。此时可以通过bt 命令查看单进程模式下函数调用的过程。如图。

   利用curl 命令。

   

 gdb  bt

2，利用strace、  pstack 调试 nginx

  a, strace 常用来跟踪进程执行时的系统调用和所接收的信号。 在Linux世界，进程不能直接访问硬件设备，当进程需要访问硬件设备(比如读取

      磁盘文件，接收网络数据等等)时，必须由用户态模式切换至内核态模式，通 过系统调用访问硬件设备。strace可以跟踪到一个进程产生的系

     统调用,包括参数，返回值，执行消耗的时间。 此外命令 ltrace 用来查看 动态库函数调用。

 b, 那具体是哪一个函数调用呢？在strace输出结果中并不能找到答案，因其输出显示都是系统调用，要显示程序中函数调用栈信息，就轮到pstack

    上场了。pstack是一个脚本工具，其核心实现就是使用了gdb以及thread apply all bt命令.

  可以通过命令 man 来 查看 Man手册中 strace、ltrace、pstack的具体具体用法。

 我们在此 修改 nginx的配置文件 nginx.conf  使其为 仅具有 一个 master 进程和一个 worker进程.  把1中修改的 master_process  off; 注解掉 加上 #

 并在配置文件上加上 worker_processes  1;

 关闭之前的nginx 重新启动 nginx。 利用命令： ps -ef | grep nginx  查看当前存在的nginx进程，然后用strace 命令的参数 -p 选项跟踪 Nginx 工作进程，如图。

  可以看到工作进程阻塞在 epoll_wait 系统调用上，因为此时没有客户端请求，nginx就阻塞于此，在另一个终端执行curl 命令： curl -I localhost ，

  再来看strace输出 结果如图。

strace输出的每一行记录一次系统调用，等号左边是系统调用名以及调用参数，等号右边是该系统调用的返回值。

通过上面的系统调用我们可以做出如下分析：

 ⑴.   epoll_wait返回值为1，表示有1个描述符存在可读/写事件，这里当然是可读事件。
 ⑵.   accept4接受该请求，返回的数字3表示socket的文件描述符。
 ⑶.   epoll_ctl把accept4建立的socket套接字（注意参数3）加入到事件监听机制里。
 ⑷.   recv从发生可读事件的socket文件描述符内读取数据，读取的数据存在第二个参数内，读取了79个字节。
 ⑸.   stat64判断客户端请求的html文件是否存在，返回值为0表示存在。
 ⑹.   open/fstat64打开并获取文件状态信息。open文件返回的文件描述符为9，后面几个系统调用都用到这个值。
 ⑺.   writev把响应头通过文件描述符3代表的socket套接字发给客户端。
 ⑻.   sendfile64把文件描述符9代表的响应体通过文件描述符3代表的socket套接字发给客户端。
 ⑼.   再往文件描述符4代表的日志文件内write一条日志信息。
 ⑽.   recv看客户端是否还发了其它待处理的请求/信息。
 ⑾.   最后关闭文件描述符3代表的socket套接字。
  由于strace能够提供nginx执行过程中的这些内部信息，所以在出现一些奇怪现象，比如nginx启动失败、响应的文件数据和预期不一致、莫名其妙

  的Segment Fault段错误、存在性能瓶颈（利用-T选项跟踪各个函数的消耗时间），利用strace也许能提供一些相关帮助。最后，要退出strace跟踪，按ctrl+c即可。

详细介绍strace 参数：

-c 统计每一系统调用的所执行的时间,次数和出错的次数等.
-d 输出strace关于标准错误的调试信息. 
-f 跟踪由fork调用所产生的子进程. 
-ff 如果提供-o filename,则所有进程的跟踪结果输出到相应的filename.pid中,pid是各进程的进程号. 
-F 尝试跟踪vfork调用.在-f时,vfork不被跟踪. 
-h 输出简要的帮助信息. 
-i 输出系统调用的入口指针. 
-q 禁止输出关于脱离的消息. 
-r 打印出相对时间关于,,每一个系统调用. 
-t 在输出中的每一行前加上时间信息. 
-tt 在输出中的每一行前加上时间信息,微秒级. 
-ttt 微秒级输出,以秒了表示时间. 
-T 显示每一调用所耗的时间. 
-v 输出所有的系统调用.一些调用关于环境变量,状态,输入输出等调用由于使用频繁,默认不输出. 
-V 输出strace的版本信息. 
-x 以十六进制形式输出非标准字符串 
-xx 所有字符串以十六进制形式输出. 
-a column 
设置返回值的输出位置.默认 为40. 
-e expr 
指定一个表达式,用来控制如何跟踪.格式如下: 
[qualifier=][!]value1[,value2]... 
qualifier只能是 trace,abbrev,verbose,raw,signal,read,write其中之一.value是用来限定的符号或数字.默认的 qualifier是 trace.感叹号是否定符号.例如:
-eopen等价于 -e trace=open,表示只跟踪open调用.而-etrace!=open表示跟踪除了open以外的其他调用.有两个特殊的符号 all 和 none.
注意有些shell使用!来执行历史记录里的命令,所以要使用\\. 
-e trace=set 
只跟踪指定的系统 调用.例如:-e trace=open,close,rean,write表示只跟踪这四个系统调用.默认的为set=all. 
-e trace=file 
只跟踪有关文件操作的系统调用. 
-e trace=process 
只跟踪有关进程控制的系统调用. 
-e trace=network 
跟踪与网络有关的所有系统调用. 
-e strace=signal 
跟踪所有与系统信号有关的 系统调用 
-e trace=ipc 
跟踪所有与进程通讯有关的系统调用 
-e abbrev=set 
设定 strace输出的系统调用的结果集.-v 等与 abbrev=none.默认为abbrev=all. 
-e raw=set 
将指 定的系统调用的参数以十六进制显示. 
-e signal=set 
指定跟踪的系统信号.默认为all.如 signal=!SIGIO(或者signal=!io),表示不跟踪SIGIO信号. 
-e read=set 
输出从指定文件中读出 的数据.例如: 
-e read=3,5 
-e write=set 
输出写入到指定文件中的数据. 
-o filename 
将strace的输出写入文件filename 
-p pid 
跟踪指定的进程pid. 
-s strsize 
指定输出的字符串的最大长度.默认为32.文件名一直全部输出. 
-u username 
以username 的UID和GID执行被跟踪的命令

strace 通用的完整用法：

strace -o output.txt -T -tt -e trace=all -p 10423

上面的含义是 跟踪28979进程的所有系统调用（-e trace=all），并统计系统调用的花费时间，以及开始时间（并以可视化的时分秒格式显示），最后将记录结果存在

output.txt文件里面。

限制strace只跟踪特定的系统调用:

如果你已经知道你要找什么，你可以让strace只跟踪一些类型的系统调用。例如，在nginx执行程序时，你需要监视的系统调用epoll_wait。

让strace只记录epoll_wait的调用用这个命令：

strace -f -o epoll-strace.txt -e epoll_wait -p 10423

命令strace跟踪的是系统调用，对于nginx本身的函数调用关系无法给出更为明朗的信息，如果我们发现nginx当前运行不正常，想知道nginx当前内部到底在执行什么函数，

那么命令pstack就是一个非常方便实用的工具。pstack的使用也非常简单，后面跟进程id即可，比如在无客户端请求的情况下，nginx阻塞在epoll_wait系统调用处，此时

利用pstack查看到的nginx函数调用堆栈关系如下：

从main()函数到epoll_wait()函数的调用关系一目了然，和在gdb内看到的堆栈信息一样。我们可以利用此进行分析优化等。

除了 1,2 还有方法 加桩调试等方法在此不再叙述。以后有机会可以介绍下特殊应用逻辑的调试。