worker process exited on signal 11 (core dumped)

moonbingbing · 2012-07-18T15:02:26+00:00

Hello! 2012/7/17 lyerwtyr <lye...@gmail.com>: > 你好我自己没有向memcached插入数...

worker process exited on signal 11 (core dumped)

moonbingbing

最近升级openresty到ngx_openresty/1.2.1.7，发现ngx_lua会导致nginx子进程崩溃，报错：worker process exited on signal 11 (core dumped)

ngx_openresty/1.0.11.28中不会出现这个问题

nginx的debug log 和core dump见附件（功力尚浅，没有分析出来问题所在...），请高手指教

Attachment: error.log
Description: Binary data

Attachment: core.12714
Description: Binary data

wendal1985

附上配置信息吧, 方便春哥调试呢

在 2012年7月18日下午3:02，Wayne <moonb...@gmail.com>写道：

最近升级openresty到ngx_openresty/1.2.1.7，发现ngx_lua会导致nginx子进程崩溃，报错：worker process exited on signal 11 (core dumped)
ngx_openresty/1.0.11.28中不会出现这个问题

nginx的debug log 和core dump见附件（功力尚浅，没有分析出来问题所在...），请高手指教

--
Wendal Chen
GuangDong China

agentzh

Hello!

2012/7/18 Wayne <moonb...@gmail.com>:
> 最近升级openresty到ngx_openresty/1.2.1.7，发现ngx_lua会导致nginx子进程崩溃，报错：worker process
> exited on signal 11 (core dumped)
> ngx_openresty/1.0.11.28中不会出现这个问题
> nginx的debug log 和core dump见附件（功力尚浅，没有分析出来问题所在...），请高手指教
>

多谢报告！不过我直接处理你附件的 core 文件会比较麻烦，因为我的系统环境很可能很不相同。能否使用 gdb 获取一下崩溃时的
backtrace? 见这里的步骤：

    http://wiki.nginx.org/Debugging#Core_dump

Thanks!
-agentzh

moonbingbing

谢春哥回复。gdb 获取了两个core文件的 backtrace full 结果，见附件。

本来想构造一个能重现的案例，可是应用代码比较复杂，还没有剥离出来能重现的代码...

2012/7/19 agentzh <age...@gmail.com>

Hello!

2012/7/18 Wayne <moonb...@gmail.com>:

> 最近升级openresty到ngx_openresty/1.2.1.7，发现ngx_lua会导致nginx子进程崩溃，报错：worker process
> exited on signal 11 (core dumped)
> ngx_openresty/1.0.11.28中不会出现这个问题
> nginx的debug log 和core dump见附件（功力尚浅，没有分析出来问题所在...），请高手指教
>

多谢报告！不过我直接处理你附件的 core 文件会比较麻烦，因为我的系统环境很可能很不相同。能否使用 gdb 获取一下崩溃时的
backtrace? 见这里的步骤：

http://wiki.nginx.org/Debugging#Core_dump

Thanks!
-agentzh

Attachment: gdb.log
Description: Binary data

Attachment: gdb_2.log
Description: Binary data

agentzh

Hello!

2012/7/18 Wayne <moonb...@gmail.com>:
> 谢春哥回复。gdb 获取了两个core文件的 backtrace full 结果，见附件。
> 本来想构造一个能重现的案例，可是应用代码比较复杂，还没有剥离出来能重现的代码...
>

你提供的两个 backtrace 反映的是同一个问题，非常有价值。能否在 gdb 里再输几个命令并把输出贴出来看看？

    p ctx->request
    p ctx->request->pool
    p ctx->regex_sd

多谢，多谢！
-agentzh

moonbingbing

第一个core：

(gdb) p ctx->request

$1 = (ngx_http_request_t *) 0x5ff0b0140e3c8b0

(gdb) p ctx->request->pool

Cannot access memory at address 0x5ff0b0140e3c908

(gdb) p ctx->regex_sd

$2 = (pcre_extra *) 0x40e2642000000000

第二个core：

(gdb) p ctx->request

$1 = (ngx_http_request_t *) 0x2b

(gdb) p ctx->request->pool

Cannot access memory at address 0x83

(gdb) p ctx->regex_sd

$2 = (pcre_extra *) 0x41974e58

多谢春哥

2012/7/19 agentzh <age...@gmail.com>

Hello!

2012/7/18 Wayne <moonb...@gmail.com>:

> 谢春哥回复。gdb 获取了两个core文件的 backtrace full 结果，见附件。
> 本来想构造一个能重现的案例，可是应用代码比较复杂，还没有剥离出来能重现的代码...
>

你提供的两个 backtrace 反映的是同一个问题，非常有价值。能否在 gdb 里再输几个命令并把输出贴出来看看？

p ctx->request
p ctx->request->pool
p ctx->regex_sd

多谢，多谢！

-agentzh

agentzh

Hello!

2012/7/18 Wayne <moonb...@gmail.com>:
> 第一个core：
> (gdb) p ctx->request
> $1 = (ngx_http_request_t *) 0x5ff0b0140e3c8b0
> (gdb) p ctx->request->pool
> Cannot access memory at address 0x5ff0b0140e3c908
> (gdb) p ctx->regex_sd
> $2 = (pcre_extra *) 0x40e2642000000000
>
> 第二个core：
> (gdb)  p ctx->request
> $1 = (ngx_http_request_t *) 0x2b
> (gdb) p ctx->request->pool
> Cannot access memory at address 0x83
> (gdb) p ctx->regex_sd
> $2 = (pcre_extra *) 0x41974e58
>

Okay，这些输出清楚地指示出 ctx 指针指向的内存区域已不再包含合法数据。我已经在源码中确认了这是由于 Lua GC 在 nginx
请求 cleanup 调用之前就已经释放了 ctx 指针指向的内存区域（ctx 指向的内存块是通过 Lua GC 分配的），所以导致 ctx
在 cleanup 回调中的非法使用。

下面这个最小化的测试可以可靠地复现这个问题：

    location /re {
        content_by_lua '
            local a = {}
            for i = 1, 3 do
                it = ngx.re.gmatch("hello, world", "[a-z]+")
                it()
                collectgarbage()
                table.insert(a, {"hello", "world"})
            end
            ngx.say("done")
        ';
    }

这个衰退是由一个月前提交的这个补丁引入的：

   https://github.com/chaoslawful/lua-nginx-module/commit/b30b56cf

最早出现在了 ngx_lua 0.5.0rc30 和 ngx_openresty 1.0.15.9 中，所以难怪你使用
ngx_openresty 1.0.11.28 是没有问题的 :)

我刚提交了一个补丁修正了此问题：

    https://github.com/chaoslawful/lua-nginx-module/commit/e73e244

Thanks!
-agentzh

agentzh

Hello!

2012/7/19 agentzh <age...@gmail.com>:
> 最早出现在了 ngx_lua 0.5.0rc30 和 ngx_openresty 1.0.15.9 中，所以难怪你使用
> ngx_openresty 1.0.11.28 是没有问题的 :)
>
> 我刚提交了一个补丁修正了此问题：
>
>     https://github.com/chaoslawful/lua-nginx-module/commit/e73e244
>

我刚刚标记了 ngx_lua v0.5.8rc1，包含了此修复。请尝试一下 ngx_openresty 1.2.1.9rc1，内含这个新版本的 ngx_lua:

    http://agentzh.org/misc/nginx/ngx_openresty-1.2.1.9rc1.tar.gz

多谢！
-agentzh

moonbingbing

换用此版本没有再出现崩溃的情况:)

春哥授人以渔，赞

2012/7/20 agentzh <age...@gmail.com>

Hello!

2012/7/19 agentzh <age...@gmail.com>:

> 最早出现在了 ngx_lua 0.5.0rc30 和 ngx_openresty 1.0.15.9 中，所以难怪你使用
> ngx_openresty 1.0.11.28 是没有问题的 :)
>
> 我刚提交了一个补丁修正了此问题：
>
> https://github.com/chaoslawful/lua-nginx-module/commit/e73e244
>

我刚刚标记了 ngx_lua v0.5.8rc1，包含了此修复。请尝试一下 ngx_openresty 1.2.1.9rc1，内含这个新版本的 ngx_lua:

http://agentzh.org/misc/nginx/ngx_openresty-1.2.1.9rc1.tar.gz

多谢！

-agentzh