《深入剖析Nginx》——2.6 特殊应用逻辑的调试

本节书摘来自异步社区《深入剖析nginx》一书中的第2章，第2.6节,作者： 高群凯 更多章节内容可以访问云栖社区“异步社区”公众号查看。

前面所讲的调试方法都是针对nginx本身很容易跑到的逻辑，而对于某些只有在特定情况下才会被执行到的代码，又该怎样去调试呢？举个例子，我们知道nginx里有大量的超时处理，比如，如果读取客户端请求头部数据超时，nginx就将执行对应的超时处理函数，假设我想通过单步执行的方式来了解这部分相关逻辑，无疑就得让nginx的执行逻辑走到这条路径上来。由于此时影响nginx行为的决定因素是客户端所发送的请求头部数据，我们就必须在客户端做动作来构造出这种场景。一般的浏览器，如ie、firefox等发出请求的行为基本已经固定，而常用的命令行工具，比如curl、wget的源代码又略显复杂，定制它们的请求动作和改变环境来构造所需的场景相对较为麻烦，所以一种更便利的方法就是我们自己写个socket通信的客户端即可，而这并不需要多少代码。

下面给出一个测试示例用代码，为了简单，所以服务器ip和端口都是固定在代码里的，用于发送数据的函数write()调用也未做返回值判断等（后续还有其他类似测试代码也是如此，这点请注意）。

该程序的代码比较简单，变量req_header存储的是http请求头部数据，被注释掉的是正常的请求头，而我这里使用的请求头是不完整的（正常请求头可以用wget、curl或wireshark1等工具获得，异常请求头必须根据自己所预期场景来进行构造，比如在这里，其他异常情况的请求头可能导致nginx以其他错误方式返回而不是进行超时监控），所以这会使得nginx在接收到该请求后，持续等待进一步的头部数据，直到超时。编译这个源代码得到应用程序request_timeout。

将接受http请求的nginx工作进程绑定到gdb，然后在超时函数ngx_event_expire_timers()内的第149行下断点并按c继续。

这个断点是nginx已经捕获到超时事件，设置其超时旗标并调用对应的回调函数进行处理。在另一个gdb内执行request_timeout，当然，我们需要让它停止在第47行2，避免程序退出，导致它与nginx工作进程之间的连接断开。等待约60秒（nginx读取请求头部数据的默认超时时间为60秒，可通过配置指令client_header_timeout修改）后，attach到nginx工作进程的gdb就会断下来，按s跟进函数，再顺着执行路径而下就会发现此时nginx将执行到这个逻辑里。

将执行到第976行的if判断内部，即连接超时，我们看到对于在读取请求头部数据超时的情况下，nginx工作进程最后所做的几步主要工作，即日志记录、关闭请求并返回。通过这样一个实例，我们也就了解了如何去调试这样的特殊应用逻辑，不仅仅只是针对客户端，对于后端应用服务器也能如此进行模拟构造。

上面演示的环境构造步骤，虽然比较简单且能真实模拟，但毕竟需要我们了解它的细节，也就是需知道触发这种情况的前提条件，如果前提条件比较多，那么模拟起来可能还是比较麻烦，其实，如果我们只是了解一下nginx如果这样执行会怎么样，那么完全可以通过利用gdb的p命令或set命令修改对应条件变量的值来达到目的。比如在前面的例子里，在一般情况下，rev->timedout为0，即不超时而无法执行第977-980行代码，但我又想看一下执行这几条语句的情况会怎么样，那么就可以像下面这样做。

通过执行“p rev->timedout=1”把变量rev->timedout的值改为1，这样就执行到第977行了，当然，如上所示，set命令也可以改变nginx执行变量的值。值得特别注意的是，这样做仅仅只是因为改变了条件判断的变量值而使得nginx程序执行路径发生变化，但是其在新的路径上，可能由于使用的某些变量值不是原本所期望的情况而导致执行异常。