Nginx學習之十四 GDB除錯Nginx初試

本文的測試環境：

win7+虛擬機器vmwarevmware-workstation-full-7.1.4-385536+ubuntu12.04

nginx-1.4.0

要想有效的研究nginx原始碼，必須要動手除錯，gdb就是有用的利器。下面簡要介紹用gdb除錯nginx的乙個小例子。

本文完成了這樣的工作：跟蹤worker子程序，觀察worker子程序阻塞在何處。然後利用wget向nginx傳送乙個訊息，觀察整個訊息處理過程。

關於gdb除錯nginx，有一篇博文講的很不錯，可以參考下：利用gdb除錯nginx。這篇部落格的作者lenky即《深入剖析nginx》的作者。這本書講的也不錯，正在研究中。

我們以預設的nginx配置來進行除錯，即master模式。

首先我們切換工作目錄至：.../nginx-1.4.-/objs/,然後在終端中啟動gdb偵錯程式：sudo gdb -q -tui（q選項是以安靜模式啟動，不顯示gdb版本等資訊。tui選項可以顯示**介面）

然後在gdb中啟動nginx：shell ./nginx

啟動之後，可以檢視當前nginx中的程序號：shell pidof nginx

也可以在另乙個終端中通過下列命令來檢視：

我們可以用attach命令來跟蹤子程序：

我們知道，子程序即worker程序在執行後會停留在epoll_wait處等待相應的事件發生，而這個函式呼叫被封裝在ngx_process_events_and_timers 中。於是我們在這個函式出設定乙個斷點：b ngx_process_events_and_timers

然後採用命令c，使得nginx一直執行，直到遇到第乙個斷點：

我們知道處理事件的方法是ngx_process_events，於是我們跟蹤進去這個函式：

s命令跟蹤進函式裡面：

我們用n命令繼續向下執行，當執行到epoll_wait函式的時候，發現程序停留在這裡，不能在向下執行。這就驗證了：worker子程序阻塞在epoll_wait函式呼叫處。

這時，我們在另乙個終端執行下列命令，以向nginx傳送訊息：wget www.web_test2.com（預先在etc/hosts檔案中加入下列行：192.168.2.129 www.web_test2.com.其中192.168.2.129 是本機ip）

終端顯示，請求已經傳送，正在等待回應。

在gdb中用n命令繼續執行，直到跳出ngx_process_events函式介面。

其實我們可以通過檢視棧幀來看函式呼叫的整個過程：bt

繼續執行，最後wget命令的那個終端會收到伺服器端的響應：