求助！ nginx运行时卡住

realmikojordan · 2012-09-28T10:14:48+00:00

Hello! 2012/9/27 junwei shi <aloh...@gmail.com>: > RT > nginx是否支持在location外设置一&#x...

求助！ nginx运行时卡住

realmikojordan

很奇怪的现象， nginx启动后开始没问题。 过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%， 但是ps 查看
进程还在， 就是不能处理请求了。 而且一直保持这种状态， 除非kill掉旧的进程， 重启nginx才能恢复。这是怎么回事呢？？

alohadc13

可以用strace -p pid看下究竟nginx在做什么

On Friday, September 28, 2012 10:14:49 AM UTC+8, 陈伟 wrote:

很奇怪的现象， nginx启动后开始没问题。过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%，但是ps 查看
进程还在，就是不能处理请求了。而且一直保持这种状态，除非kill掉旧的进程，重启nginx才能恢复。这是怎么回事呢？？

realmikojordan

已经重启过了。。。 没机会了。。。。
依据您的经验， 可能会有哪些原因呢？


On 9月28日, 上午10时16分, junwei shi <alohad...@gmail.com> wrote:
> 可以用strace -p pid看下究竟nginx在做什么
>
>
>
>
>
>
>
> On Friday, September 28, 2012 10:14:49 AM UTC+8, 陈伟 wrote:
>
> > 很奇怪的现象， nginx启动后开始没问题。 过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%， 但是ps 查看
> > 进程还在， 就是不能处理请求了。 而且一直保持这种状态， 除非kill掉旧的进程， 重启nginx才能恢复。这是怎么回事呢？？

agentzh

Hello!

在 2012年9月27日星期四，陈伟写道：

已经重启过了。。。没机会了。。。。
依据您的经验，可能会有哪些原因呢？

保留第一现场是最重要的。下次记得分别用 pstack 和 strace 获取用户态调用栈和系统调用的若干样本，否则信息严重不足，无法帮你诊断。

agentzh

On 9月28日, 上午10时16分, junwei shi <alohad...@gmail.com> wrote:
> 可以用strace -p pid看下究竟nginx在做什么
>
>
>
>
>
>
>
> On Friday, September 28, 2012 10:14:49 AM UTC+8, 陈伟 wrote:
>
> > 很奇怪的现象， nginx启动后开始没问题。过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%，但是ps 查看
> > 进程还在，就是不能处理请求了。而且一直保持这种状态，除非kill掉旧的进程，重启nginx才能恢复。这是怎么回事呢？？

lancelijade

正好我也碰到这个问题了，现在这台机器有两个worker正处在这个状态，其他worker还能正常服务，pstack每次运行输出都在变化，strace -p 运行若干秒后没有任何输出

[root@p72 ~]# pstack 23292
#0 0x00002b0bb38891a9 in lua_rawget () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#1 0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()
#2 0x00002b0bb387da03 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#3 0x000000000048e1ef in ngx_http_lua_run_thread ()
#4 0x000000000049080d in ngx_http_lua_content_by_chunk ()
#5 0x00000000004908e8 in ngx_http_lua_content_handler_inline ()
#6 0x0000000000490637 in ngx_http_lua_content_handler ()
#7 0x000000000043ca21 in ngx_http_core_content_phase ()
#8 0x0000000000437e63 in ngx_http_core_run_phases ()
#9 0x0000000000437f60 in ngx_http_handler ()
#10 0x000000000044176d in ngx_http_process_request ()
#11 0x0000000000441f90 in ngx_http_process_request_headers ()
#12 0x000000000042aa46 in ngx_event_process_posted ()
#13 0x000000000042a909 in ngx_process_events_and_timers ()
#14 0x00000000004306bd in ngx_worker_process_cycle ()
#15 0x000000000042ef27 in ngx_spawn_process ()
#16 0x000000000042fd9c in ngx_start_worker_processes ()
#17 0x000000000043120a in ngx_master_process_cycle ()
#18 0x0000000000415c7a in main ()
[root@p72 ~]# strace -p 23292
Process 23292 attached - interrupt to quit
Process 23292 detached
[root@p72 ~]# pstack 23290
#0 0x00002b0bb3882c3b in hashkey () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#1 0x00002b0bb3882ed0 in lj_tab_get () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#2 0x00002b0bb38891bb in lua_rawget () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#3 0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()
#4 0x00002b0bb387da03 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#5 0x000000000048e1ef in ngx_http_lua_run_thread ()
#6 0x000000000049080d in ngx_http_lua_content_by_chunk ()
#7 0x00000000004908e8 in ngx_http_lua_content_handler_inline ()
#8 0x0000000000490637 in ngx_http_lua_content_handler ()
#9 0x000000000043ca21 in ngx_http_core_content_phase ()
#10 0x0000000000437e63 in ngx_http_core_run_phases ()
#11 0x0000000000437f60 in ngx_http_handler ()
#12 0x000000000044176d in ngx_http_process_request ()
#13 0x0000000000441f90 in ngx_http_process_request_headers ()
#14 0x000000000042aa46 in ngx_event_process_posted ()
#15 0x000000000042a909 in ngx_process_events_and_timers ()
#16 0x00000000004306bd in ngx_worker_process_cycle ()
#17 0x000000000042ef27 in ngx_spawn_process ()
#18 0x000000000042fd9c in ngx_start_worker_processes ()
#19 0x000000000043120a in ngx_master_process_cycle ()
#20 0x0000000000415c7a in main ()
[root@p72 ~]# strace -p 23290
Process 23290 attached - interrupt to quit
Process 23290 detached

Lance

2012/9/28 agentzh <age...@gmail.com>

Hello!

在 2012年9月27日星期四，陈伟写道：
已经重启过了。。。没机会了。。。。
依据您的经验，可能会有哪些原因呢？

保留第一现场是最重要的。下次记得分别用 pstack 和 strace 获取用户态调用栈和系统调用的若干样本，否则信息严重不足，无法帮你诊断。

agentzh

On 9月28日, 上午10时16分, junwei shi <alohad...@gmail.com> wrote:
> 可以用strace -p pid看下究竟nginx在做什么
>
>
>
>
>
>
>
> On Friday, September 28, 2012 10:14:49 AM UTC+8, 陈伟 wrote:
>
> > 很奇怪的现象， nginx启动后开始没问题。过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%，但是ps 查看
> > 进程还在，就是不能处理请求了。而且一直保持这种状态，除非kill掉旧的进程，重启nginx才能恢复。这是怎么回事呢？？

lancelijade

补充一下版本
nginx version: ngx_openresty/1.2.1.14
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-51)

Lance

2012/9/28 Lance <lance...@gmail.com>

正好我也碰到这个问题了，现在这台机器有两个worker正处在这个状态，其他worker还能正常服务，pstack每次运行输出都在变化，strace -p 运行若干秒后没有任何输出

[root@p72 ~]# pstack 23292
#0 0x00002b0bb38891a9 in lua_rawget () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#1 0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()
#2 0x00002b0bb387da03 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#3 0x000000000048e1ef in ngx_http_lua_run_thread ()
#4 0x000000000049080d in ngx_http_lua_content_by_chunk ()
#5 0x00000000004908e8 in ngx_http_lua_content_handler_inline ()
#6 0x0000000000490637 in ngx_http_lua_content_handler ()
#7 0x000000000043ca21 in ngx_http_core_content_phase ()
#8 0x0000000000437e63 in ngx_http_core_run_phases ()
#9 0x0000000000437f60 in ngx_http_handler ()
#10 0x000000000044176d in ngx_http_process_request ()
#11 0x0000000000441f90 in ngx_http_process_request_headers ()
#12 0x000000000042aa46 in ngx_event_process_posted ()
#13 0x000000000042a909 in ngx_process_events_and_timers ()
#14 0x00000000004306bd in ngx_worker_process_cycle ()
#15 0x000000000042ef27 in ngx_spawn_process ()
#16 0x000000000042fd9c in ngx_start_worker_processes ()
#17 0x000000000043120a in ngx_master_process_cycle ()
#18 0x0000000000415c7a in main ()
[root@p72 ~]# strace -p 23292
Process 23292 attached - interrupt to quit
Process 23292 detached
[root@p72 ~]# pstack 23290
#0 0x00002b0bb3882c3b in hashkey () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#1 0x00002b0bb3882ed0 in lj_tab_get () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#2 0x00002b0bb38891bb in lua_rawget () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#3 0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()
#4 0x00002b0bb387da03 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#5 0x000000000048e1ef in ngx_http_lua_run_thread ()
#6 0x000000000049080d in ngx_http_lua_content_by_chunk ()
#7 0x00000000004908e8 in ngx_http_lua_content_handler_inline ()
#8 0x0000000000490637 in ngx_http_lua_content_handler ()
#9 0x000000000043ca21 in ngx_http_core_content_phase ()
#10 0x0000000000437e63 in ngx_http_core_run_phases ()
#11 0x0000000000437f60 in ngx_http_handler ()
#12 0x000000000044176d in ngx_http_process_request ()
#13 0x0000000000441f90 in ngx_http_process_request_headers ()
#14 0x000000000042aa46 in ngx_event_process_posted ()
#15 0x000000000042a909 in ngx_process_events_and_timers ()
#16 0x00000000004306bd in ngx_worker_process_cycle ()
#17 0x000000000042ef27 in ngx_spawn_process ()
#18 0x000000000042fd9c in ngx_start_worker_processes ()
#19 0x000000000043120a in ngx_master_process_cycle ()
#20 0x0000000000415c7a in main ()
[root@p72 ~]# strace -p 23290
Process 23290 attached - interrupt to quit
Process 23290 detached

Lance

2012/9/28 agentzh <age...@gmail.com>
Hello!

在 2012年9月27日星期四，陈伟写道：
已经重启过了。。。没机会了。。。。
依据您的经验，可能会有哪些原因呢？

保留第一现场是最重要的。下次记得分别用 pstack 和 strace 获取用户态调用栈和系统调用的若干样本，否则信息严重不足，无法帮你诊断。

agentzh

On 9月28日, 上午10时16分, junwei shi <alohad...@gmail.com> wrote:
> 可以用strace -p pid看下究竟nginx在做什么
>
>
>
>
>
>
>
> On Friday, September 28, 2012 10:14:49 AM UTC+8, 陈伟 wrote:
>
> > 很奇怪的现象， nginx启动后开始没问题。过一段时间（具体也不清楚多久），就会发现nginx进程占用cpu 达到100%，但是ps 查看
> > 进程还在，就是不能处理请求了。而且一直保持这种状态，除非kill掉旧的进程，重启nginx才能恢复。这是怎么回事呢？？

agentzh

Hello!

2012/9/27 Lance <lance...@gmail.com>:
> 正好我也碰到这个问题了，现在这台机器有两个worker正处在这个状态，其他worker还能正常服务，pstack每次运行输出都在变化，strace -p
> 运行若干秒后没有任何输出
>
> [root@p72 ~]# pstack 23292
> #0  0x00002b0bb38891a9 in lua_rawget () from
> /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
> #1  0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()

貌似你的 Lua 代码在调用 ngx.re.gmatch() 返回的迭代器时热循环了。你可以借助 gdb 定位一下事件具体发生在你的 Lua
代码的哪个位置上（如果你有多处使用 ngx.re.match 的话）。

下面是一个演示例子。我造了一个 ngx.re.gmatch 死循环的例子：

    location = /t {
        content_by_lua '
            function foo()
                bar()
            end

            function bar()
                it = ngx.re.gmatch("hello", "i")
                while true do
                    it()
                end
            end

            foo()
        ';
    }

然后启动 nginx，用 curl 访问 /t 接口，nginx 确实就进入 CPU 100%
的状态。此时，我把晓哲老师编写的这个文件保存为我本地的 ~/.gdbinit 文件：

    https://raw.github.com/chaoslawful/lua-nginx-module/master/util/gdbinit

里面定义了若干调试 Lua/LuaJIT 的 gdb 宏。然后使用 gdb 7.1 以上版本（我本地是 gdb
7.4.50）绑定到热循环的那个 nginx 进程上（在我这里 pid 为 2501）：

    $ gdb -p 2501

然后在 gdb 提示符后，用 bt 命令显示当前的 C 调用栈：

    (gdb) bt
    #0  ngx_http_lua_ngx_re_gmatch_iterator (L=0x417af5d8) at
src/ngx_http_lua_regex.c:979
    #1  0x00007f8b44dec0e7 in lj_BC_FUNCC () from lib/libluajit-5.1.so.2
    #2  0x00000000004a38c6 in ngx_http_lua_run_thread
(L=L@entry=0x417a3378, r=r@entry=0x926d30, ctx=ctx@entry=0x92b720,
        nret=nret@entry=0) at src/ngx_http_lua_util.c:912
    #3  0x00000000004a6773 in ngx_http_lua_content_by_chunk
(L=L@entry=0x417a3378, r=r@entry=0x926d30)
        at src/ngx_http_lua_contentby.c:86
    #4  0x00000000004a6b50 in ngx_http_lua_content_handler_inline (r=0x926d30)
        at src/ngx_http_lua_contentby.c:291
    #5  0x00000000004a6904 in ngx_http_lua_content_handler (r=0x926d30)
        at src/ngx_http_lua_contentby.c:186
    ...

这里第 0 帧就有 Lua 虚拟机的 state，即 L 参数，如果第 0 帧没有，则需要跳到有 L 参数的那一帧，例如上面的第 2 帧也有 L 参数：

    (gdb) fr 2

然后输入命令 lbt L 便可以得到 Lua 当前的调用栈：

    (gdb) lbt L
    #0	it	[C]	at =[C]:-1
    #1	bar	[Lua]	at content_by_lua:9
    #2	foo	[Lua]	at content_by_lua:3
    #3	???	[Lua]	at content_by_lua:13

这正好完全符合我们上面伪造的那个例子中死循环的位置。

当然，更方便的做法是把上面的步骤封装成一个独立的 shell 脚本全部自动化，就像 pstack 那样。不过眼下先救你的急哈 :)

多谢！
-agentzh

agentzh

Hello!

2012/9/27 agentzh <age...@gmail.com>:
> 这里第 0 帧就有 Lua 虚拟机的 state，即 L 参数，如果第 0 帧没有，则需要跳到有 L 参数的那一帧，例如上面的第 2 帧也有 L 参数：
>
>     (gdb) fr 2
>

当然，在这个例子里，不能使用第 2 帧而只能使用第 0 帧，因为 ngx_http_lua_run_thread 函数的第一个参数 L
并不是当前正在运行 Lua 协程的 L，而是主线程的 L，所以如果在此例中，先切到第 2 帧再用 lbt L
命令会得到空输出，因为虚拟机的主 thread 里并没有调用栈。所以这里只能切到第 0 帧。

Best regards,
-agentzh

lancelijade

应该是 pattern 不合法所致，比如这样就会让 worker 死在那里

    server
    {
        listen 81;
        access_log /data/logs/81.access.log combined;
        error_log /data/logs/81.error.log warn;

        location / {
            content_by_lua '
                local s = "aaaabbbb"
                local r = {}
                local pattern = "a|"
                for m in ngx.re.gmatch(s, pattern, "ijo") do
                    r[#r+1] = m[1]
                end
                ngx.say(1)
            ';
        }
    }

另外提供我的同事 19...@gmail.com 的分析结果

当cap[n] == cap[n+1]时，ngx_http_lua_ngx_re_gmatch_iterator函数会被无限执行。

for (i = 0, n = 0; i < rc; i++, n += 2) {

dd("capture %d: %d %d", i, cap[n], cap[n + 1]);

if (cap[n] < 0) {

lua_pushnil(L);

} else {

lua_pushlstring(L, (char *) &subj.data[cap[n]],

cap[n + 1] - cap[n]);

dd("pushing capture %s at %d", lua_tostring(L, -1), (int) i);

}

lua_rawseti(L, -2, (int) i);

}

offset = cap[1]; // <------------------------------------- 看这里看这里

if (offset == (ssize_t) subj.len) {

offset = -1;

if (!(ctx->flags & NGX_LUA_RE_COMPILE_ONCE)) {

if (ctx->regex_sd) {

ngx_http_lua_regex_free_study_data(r->pool, ctx->regex_sd);

ctx->regex_sd = NULL;

}

ngx_pfree(r->pool, cap);

}

--------

(gdb) bt

#0 0x00002b0bb3888912 in lua_pushlstring () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2

#1 0x0000000000489b9f in ngx_http_lua_ngx_re_gmatch_iterator (L=0x41825948) at ../ngx_lua-0.5.14/src/ngx_http_lua_regex.c:937

#2 0x00002b0bb387da03 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2

#3 0x000000000048e1ef in ngx_http_lua_run_thread (L=0x40553378, r=0xbec0558, ctx=0xbf5cff0, nret=0) at ../ngx_lua-0.5.14/src/ngx_http_lua_util.c:850

#4 0x000000000049080d in ngx_http_lua_content_by_chunk (L=0x40553378, r=0xbec0558) at ../ngx_lua-0.5.14/src/ngx_http_lua_contentby.c:91

#5 0x00000000004908e8 in ngx_http_lua_content_handler_inline (r=0xbec0558) at ../ngx_lua-0.5.14/src/ngx_http_lua_contentby.c:296

#6 0x0000000000490637 in ngx_http_lua_content_handler (r=0xbec0558) at ../ngx_lua-0.5.14/src/ngx_http_lua_contentby.c:174

#7 0x000000000043ca21 in ngx_http_core_content_phase (r=0x41825948, ph=0xbd98298) at src/http/ngx_http_core_module.c:1407

#8 0x0000000000437e63 in ngx_http_core_run_phases (r=0xbec0558) at src/http/ngx_http_core_module.c:888

#9 0x0000000000437f60 in ngx_http_handler (r=0x41825948) at src/http/ngx_http_core_module.c:871

#10 0x000000000044176d in ngx_http_process_request (r=0xbec0558) at src/http/ngx_http_request.c:1697

#11 0x0000000000441f90 in ngx_http_process_request_headers (rev=<value optimized out>) at src/http/ngx_http_request.c:1141

#12 0x000000000042aa46 in ngx_event_process_posted (cycle=<value optimized out>, posted=0x45067032) at src/event/ngx_event_posted.c:40

#13 0x000000000042a909 in ngx_process_events_and_timers (cycle=0xbd30720) at src/event/ngx_event.c:274

#14 0x00000000004306bd in ngx_worker_process_cycle (cycle=0xbd30720, data="" optimized out>) at src/os/unix/ngx_process_cycle.c:808

#15 0x000000000042ef27 in ngx_spawn_process (cycle=0xbd30720, proc=0x4305f5 <ngx_worker_process_cycle>, data="" name=0x4c9a8c "worker process", respawn=-4)

at src/os/unix/ngx_process.c:198

#16 0x000000000042fd9c in ngx_start_worker_processes (cycle=0xbd30720, n=6, type=-4) at src/os/unix/ngx_process_cycle.c:365

#17 0x000000000043120a in ngx_master_process_cycle (cycle=0xbd30720) at src/os/unix/ngx_process_cycle.c:250

#18 0x0000000000415c7a in main (argc=38, argv=0xbcc06c0) at src/core/nginx.c:410

(gdb) frame 1

#1 0x0000000000489b9f in ngx_http_lua_ngx_re_gmatch_iterator (L=0x41825948) at ../ngx_lua-0.5.14/src/ngx_http_lua_regex.c:937

937 lua_pushlstring(L, (char *) &subj.data[cap[n]],

(gdb) print rc

$2 = 1

(gdb) print cap[0]

$3 = 18

(gdb) print cap[1]

$4 = 18

Lance

2012/9/28 agentzh <age...@gmail.com>

Hello!

2012/9/27 agentzh <age...@gmail.com>:

> 这里第 0 帧就有 Lua 虚拟机的 state，即 L 参数，如果第 0 帧没有，则需要跳到有 L 参数的那一帧，例如上面的第 2 帧也有 L 参数：
>
> (gdb) fr 2
>

当然，在这个例子里，不能使用第 2 帧而只能使用第 0 帧，因为 ngx_http_lua_run_thread 函数的第一个参数 L
并不是当前正在运行 Lua 协程的 L，而是主线程的 L，所以如果在此例中，先切到第 2 帧再用 lbt L
命令会得到空输出，因为虚拟机的主 thread 里并没有调用栈。所以这里只能切到第 0 帧。

Best regards,

-agentzh

agentzh

Hello!

On Thu, Sep 27, 2012 at 11:42 PM, Lance <lance...@gmail.com> wrote:
> 应该是 pattern 不合法所致，比如这样就会让 worker 死在那里
>
>     server
>     {
>         listen 81;
>         access_log /data/logs/81.access.log combined;
>         error_log /data/logs/81.error.log warn;
>
>         location / {
>             content_by_lua '
>                 local s = "aaaabbbb"
>                 local r = {}
>                 local pattern = "a|"
>                 for m in ngx.re.gmatch(s, pattern, "ijo") do
>                     r[#r+1] = m[1]
>                 end
>                 ngx.say(1)
>             ';
>         }
>     }
>
> 另外提供我的同事 19...@gmail.com 的分析结果
>
> 当cap[n] == cap[n+1]时，ngx_http_lua_ngx_re_gmatch_iterator函数会被无限执行。
>

多谢你提供的用例和原因分析！我刚提交了两个补丁，应当修正了这个问题：

    https://github.com/chaoslawful/lua-nginx-module/commit/ad5e7f7
    https://github.com/chaoslawful/lua-nginx-module/commit/4b9100c

即当 ngx.re.gmatch 的匹配器匹配了一个空串时，我们仍将当前偏移量下移一个字节，同时允许模式尝试匹配字符串的末尾。

现在这里的行为终于和 Perl 5 一致了：

    $ perl -e 'while ("hello" =~ /a|/g) { print "HIT\n" }'
    HIT
    HIT
    HIT
    HIT
    HIT
    HIT

再次感谢！

Best regards,
-agentzh

lancelijade

刚才我们已经用了类似的方法，定位出了问题确实在re.gmatch 中，而且现在已经基本确定了只要 pattern里带 | 就会有问题，稍等我隔离一个最小样本出来
Lance

2012/9/28 agentzh <age...@gmail.com>

Hello!

2012/9/27 Lance <lance...@gmail.com>:

> 正好我也碰到这个问题了，现在这台机器有两个worker正处在这个状态，其他worker还能正常服务，pstack每次运行输出都在变化，strace -p
> 运行若干秒后没有任何输出
>
> [root@p72 ~]# pstack 23292
> #0 0x00002b0bb38891a9 in lua_rawget () from
> /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
> #1 0x00000000004899c4 in ngx_http_lua_ngx_re_gmatch_iterator ()

貌似你的 Lua 代码在调用 ngx.re.gmatch() 返回的迭代器时热循环了。你可以借助 gdb 定位一下事件具体发生在你的 Lua
代码的哪个位置上（如果你有多处使用 ngx.re.match 的话）。

下面是一个演示例子。我造了一个 ngx.re.gmatch 死循环的例子：

location = /t {
content_by_lua '
function foo()
bar()
end

function bar()
it = ngx.re.gmatch("hello", "i")
while true do
it()
end
end

foo()
';
}

然后启动 nginx，用 curl 访问 /t 接口，nginx 确实就进入 CPU 100%
的状态。此时，我把晓哲老师编写的这个文件保存为我本地的 ~/.gdbinit 文件：

https://raw.github.com/chaoslawful/lua-nginx-module/master/util/gdbinit

里面定义了若干调试 Lua/LuaJIT 的 gdb 宏。然后使用 gdb 7.1 以上版本（我本地是 gdb
7.4.50）绑定到热循环的那个 nginx 进程上（在我这里 pid 为 2501）：

$ gdb -p 2501

然后在 gdb 提示符后，用 bt 命令显示当前的 C 调用栈：

(gdb) bt
#0 ngx_http_lua_ngx_re_gmatch_iterator (L=0x417af5d8) at
src/ngx_http_lua_regex.c:979
#1 0x00007f8b44dec0e7 in lj_BC_FUNCC () from lib/libluajit-5.1.so.2
#2 0x00000000004a38c6 in ngx_http_lua_run_thread
(L=L@entry=0x417a3378, r=r@entry=0x926d30, ctx=ctx@entry=0x92b720,
nret=nret@entry=0) at src/ngx_http_lua_util.c:912
#3 0x00000000004a6773 in ngx_http_lua_content_by_chunk
(L=L@entry=0x417a3378, r=r@entry=0x926d30)
at src/ngx_http_lua_contentby.c:86
#4 0x00000000004a6b50 in ngx_http_lua_content_handler_inline (r=0x926d30)
at src/ngx_http_lua_contentby.c:291
#5 0x00000000004a6904 in ngx_http_lua_content_handler (r=0x926d30)
at src/ngx_http_lua_contentby.c:186
...

这里第 0 帧就有 Lua 虚拟机的 state，即 L 参数，如果第 0 帧没有，则需要跳到有 L 参数的那一帧，例如上面的第 2 帧也有 L 参数：

(gdb) fr 2

然后输入命令 lbt L 便可以得到 Lua 当前的调用栈：

(gdb) lbt L
#0 it [C] at =[C]:-1
#1 bar [Lua] at content_by_lua:9
#2 foo [Lua] at content_by_lua:3
#3 ??? [Lua] at content_by_lua:13

这正好完全符合我们上面伪造的那个例子中死循环的位置。

当然，更方便的做法是把上面的步骤封装成一个独立的 shell 脚本全部自动化，就像 pstack 那样。不过眼下先救你的急哈 :)

多谢！
-agentzh

lancelijade

这个补丁已经解决了我的问题，但它在用 | 做模板实际运行时似乎无限次循环直到遍历整个文档，这样对于比较大的文档规模情况下循环次数会非常可怕，不知能否在这种函数里加个limit控制最大匹配结果数，这样由使用者来控制，默认值如果考虑向前兼容，可以用math.huge

发自我的 iPad

在 Sep 28, 2012，3:09 PM，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> On Thu, Sep 27, 2012 at 11:42 PM, Lance <lance...@gmail.com> wrote:
>> 应该是 pattern 不合法所致，比如这样就会让 worker 死在那里
>> 
>>    server
>>    {
>>        listen 81;
>>        access_log /data/logs/81.access.log combined;
>>        error_log /data/logs/81.error.log warn;
>> 
>>        location / {
>>            content_by_lua '
>>                local s = "aaaabbbb"
>>                local r = {}
>>                local pattern = "a|"
>>                for m in ngx.re.gmatch(s, pattern, "ijo") do
>>                    r[#r+1] = m[1]
>>                end
>>                ngx.say(1)
>>            ';
>>        }
>>    }
>> 
>> 另外提供我的同事 19...@gmail.com 的分析结果
>> 
>> 当cap[n] == cap[n+1]时，ngx_http_lua_ngx_re_gmatch_iterator函数会被无限执行。
>> 
> 
> 多谢你提供的用例和原因分析！我刚提交了两个补丁，应当修正了这个问题：
> 
>    https://github.com/chaoslawful/lua-nginx-module/commit/ad5e7f7
>    https://github.com/chaoslawful/lua-nginx-module/commit/4b9100c
> 
> 即当 ngx.re.gmatch 的匹配器匹配了一个空串时，我们仍将当前偏移量下移一个字节，同时允许模式尝试匹配字符串的末尾。
> 
> 现在这里的行为终于和 Perl 5 一致了：
> 
>    $ perl -e 'while ("hello" =~ /a|/g) { print "HIT\n" }'
>    HIT
>    HIT
>    HIT
>    HIT
>    HIT
>    HIT
> 
> 再次感谢！
> 
> Best regards,
> -agentzh
> 
>

agentzh

Hello!

2012/9/28 Lance Li <lance...@gmail.com>:
> 这个补丁已经解决了我的问题，

Cool :)

我需要给其他 ngx.re API 也打上类似的补丁 :)

> 但它在用 | 做模板实际运行时似乎无限次循环直到遍历整个文档，这样对于比较大的文档规模情况下循环次数会非常可怕，不知能否在这种函数里加个limit控制最大匹配结果数，这样由使用者来控制，默认值如果考虑向前兼容，可以用math.huge
>

或许可以引入 lua_regex_max_matches 配置指令来全局限制 ngx.re.gmatch 和 ngx.re.gsub 的最大成功匹配的次数？

当然，最直接的做法是在你的 Lua 循环里面自己通过计数器变量来加以限制 :)

Best regards,
-agentzh

lancelijade

从应用开发的角度来看，直接在函数里加限制并默认一个比较小的数值感觉更加合理，这样开发者就有意识会去控制这个参数，以更适合自己的应用，如果做成全局配置指令或者干脆要求开发者自己控制，这个事情就很容易被忽略掉，直到引发出比较严重的后果时，还不容易找问题出在哪里

发自我的 iPad

在 Sep 29, 2012，2:25 AM，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> 2012/9/28 Lance Li <lance...@gmail.com>:
>> 这个补丁已经解决了我的问题，
> 
> Cool :)
> 
> 我需要给其他 ngx.re API 也打上类似的补丁 :)
> 
>> 但它在用 | 做模板实际运行时似乎无限次循环直到遍历整个文档，这样对于比较大的文档规模情况下循环次数会非常可怕，不知能否在这种函数里加个limit控制最大匹配结果数，这样由使用者来控制，默认值如果考虑向前兼容，可以用math.huge
>> 
> 
> 或许可以引入 lua_regex_max_matches 配置指令来全局限制 ngx.re.gmatch 和 ngx.re.gsub 的最大成功匹配的次数？
> 
> 当然，最直接的做法是在你的 Lua 循环里面自己通过计数器变量来加以限制 :)
> 
> Best regards,
> -agentzh
> 
>

agentzh

Hello!

2012/9/28 Lance Li <lance...@gmail.com>:
> 从应用开发的角度来看，直接在函数里加限制并默认一个比较小的数值感觉更加合理，这样开发者就有意识会去控制这个参数，以更适合自己的应用，如果做成全局配置指令或者干脆要求开发者自己控制，这个事情就很容易被忽略掉，直到引发出比较严重的后果时，还不容易找问题出在哪里
>

Perl 语言里面没有对此进行自动限制的机制，我不确定 PHP 的 PCRE
绑定是否有进行限制（其手册里似乎并未提及：http://php.net/manual/en/function.preg-match-all.php
）

我接受让 lua_regex_max_matches 指令默认为较小的值，比如 1000，但我不愿意给 ngx.re.gmatch 或者
ngx.re.gsub 再添加专门的 max_matches 参数，因为它们现有的参数已经很多了 :)

Best regards,
-agentzh

lancelijade

不管哪种方法，只要能限制，我觉得都是可以接受的，全局配置至少感觉上比完全要求开发者自己数要更可靠

Lance

2012/9/29 agentzh <age...@gmail.com>

Hello!

2012/9/28 Lance Li <lance...@gmail.com>:

> 从应用开发的角度来看，直接在函数里加限制并默认一个比较小的数值感觉更加合理，这样开发者就有意识会去控制这个参数，以更适合自己的应用，如果做成全局配置指令或者干脆要求开发者自己控制，这个事情就很容易被忽略掉，直到引发出比较严重的后果时，还不容易找问题出在哪里
>

Perl 语言里面没有对此进行自动限制的机制，我不确定 PHP 的 PCRE
绑定是否有进行限制（其手册里似乎并未提及：http://php.net/manual/en/function.preg-match-all.php
）

我接受让 lua_regex_max_matches 指令默认为较小的值，比如 1000，但我不愿意给 ngx.re.gmatch 或者
ngx.re.gsub 再添加专门的 max_matches 参数，因为它们现有的参数已经很多了 :)

Best regards,
-agentzh

agentzh

Hello!

2012/9/28 Lance:
> 不管哪种方法，只要能限制，我觉得都是可以接受的，全局配置至少感觉上比完全要求开发者自己数要更可靠
>

或许这里优先级更高的一件事情是把 ngx_lua 的 gdbinit 封装为使用便利的 lua-pstack 命令行工具 :) 比如
Perl 的 perl-stacktrace 脚本：

    http://search.cpan.org/perldoc?App::Stacktrace

更进一步，我们可以为 SystemTap 的 ubacktrace() 添加对 Lua/LuaJIT 调用栈的原生支持，届时也可以在 Lua
语言级别上绘制 flamegraph 了，就像 DTrace 社区的哥们在 Solaris 家族的系统上对 NodeJS 所做的那样：

    http://dtrace.org/blogs/dap/2012/04/25/profiling-node-js/

这一类问题最关键的是获得快速地进行实时监视和诊断的能力；“补洞”的效果还是非常有限的，而且有可能掩盖代码中真正的问题 :)

Best regards,
-agentzh