Nginx代码调试——gdb工具

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

参考网上的资料，写了一个configprint模块，其功能为打印输出location配置内容，并计数访问次数。

代码链接如下：https://github.com/PaulWeiHan/nginx_module_development

程序的编写到运行总不是一帆风顺的，编译通过，运行不过的情况是最让我抓狂的。

这里记录一下gdb调试过程。供大家参考：

（这里没有gdb命令说明，请自行百度）

我使用的是nginx的默认模式即：

daemon on;
master_process on;
worker_processes ;

我们知道。nginx默认执行的时候，是以daemon模式运行在后台，并且，由master进程fork出多个work子进程来监听端口的。切到nginx目录，执行下面命令：

gdb
shell sbin/nginx
shell pidof nginx

这样，我们就可以得到nginx的pid，一般会是两个，由于worker子进程是fork master得来的，所以自然worker进程的pid较大。利用gdb的attach和detach命令追踪worker子进程。

(gdb) shell pidof nginx(gdb) attach
Attaching to process
Reading symbols from /home/renwh/nginx/sbin/nginx...done.
Reading symbols from /lib64/libpthread.so....(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.
Reading symbols from /lib64/libcrypt.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libcrypt.so.
Reading symbols from /lib64/libpcre.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libpcre.so.
Reading symbols from /lib64/libz.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.
Reading symbols from /lib64/libc.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.
Reading symbols from /lib64/ld-linux-x86-.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-.so.
Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done.
Loaded symbols for /lib64/libfreebl3.so
Reading symbols from /lib64/libdl.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.
Reading symbols from /lib64/libnss_files.so....(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.
0x00000031684e8fb3 in __epoll_wait_nocancel () from /lib64/libc.so.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64 nss-softokn-freebl-3.14.-.el6.x86_64 pcre-7.8-.el6.x86_64 zlib-1.2.-.el6.x86_64
(gdb)

子进程即worker进程在运行后会停留在epoll_wait处等待相应的事件发生，而这个函数调用被封装在ngx_process_events_and_timers 中。于是我们在这个函数出设置一个断点：b ngx_process_events_and_timers.然后采用命令c，使得nginx一直运行，直到遇到第一个断点：

(gdb) b ngx_process_events_and_timers
Breakpoint at 0x41b565: file src/event/ngx_event.c, line .
(gdb) c
Continuing. Breakpoint , ngx_process_events_and_timers (cycle=0x9be050) at src/event/ngx_event.c:
{
(gdb)

进去之后，一直用n向下运行，直到找到ngx_process_events，然后用s追踪进该函数，一直n，直到运行到epoll_wait，发现，停在了这里，我们知道work子进程在等待事件了。

Breakpoint , ngx_process_events_and_timers (cycle=0x9be050) at src/event/ngx_event.c:
{
(gdb) n
if (ngx_timer_resolution) {
(gdb) n
timer = ngx_event_find_timer();
(gdb) n
if (ngx_use_accept_mutex) {
(gdb) n
delta = ngx_current_msec;
(gdb) n
(void) ngx_process_events(cycle, timer, flags);
(gdb) s
ngx_epoll_process_events (cycle=0x9be050, timer=, flags=)
at src/event/modules/ngx_epoll_module.c:
{
(gdb) n
events = epoll_wait(ep, event_list, (int) nevents, timer);
(gdb) n

这时候，你只需要打开一个浏览器，访问你配置好的nginx模块的url，然后你就会发现gdb可以向下运行了。这时候，你需要在你自己的handler函数处设置断点，然后c，你会发现，又一次调用了ngx_process_events_and_timers函数，s进入函数，继续c运行，然后gdb会停在你自己的handler函数入口，这里是：ngx_http_configprint_handler。s追踪进去，你就可以单步执行你自己写的handler函数，进行debug了。

(gdb) b ngx_http_configprint_handler
Breakpoint at 0x4699a7: file /home/renwh/src/nginx-1.9./configprint//ngx_http_configprint_module.c, line 184.
(gdb) c
Continuing. Breakpoint , ngx_process_events_and_timers (cycle=0x9be050) at src/event/ngx_event.c:
{
(gdb) s
if (ngx_timer_resolution) {
(gdb) n
timer = ngx_event_find_timer();
(gdb) n
if (ngx_use_accept_mutex) {
(gdb) n
delta = ngx_current_msec;
(gdb) c
Continuing. Breakpoint , ngx_http_configprint_handler (r=0x9c8550)
at /home/renwh/src/nginx-1.9./configprint//ngx_http_configprint_module.c:184
{
(gdb) n
u_char ngx_my_string[] = {};
(gdb) n
ngx_log_error(NGX_LOG_EMERG, r->connection->log, , "ngx_http_configprint_handler is