nginx core dump

believe3301

在使用nginx lua module的时候，突然爆出来一个core dump。bt的信息如下：

#0 0x0000000000006d1e in ?? ()

#1 0x00007f54c1bc4b92 in lj_cf_package_unloadlib (L=<value optimized out>) at lib_package.c:258

#2 0x00007f54c1b78e2b in lj_BC_FUNCC () from /opt/nginx/libs/libluajit-5.1.so.2

#3 0x00007f54c1b7bb09 in gc_call_finalizer (g=<value optimized out>, L=0x41b5c378, mo=<value optimized out>, o=<value optimized out>) at lj_gc.c:473

#4 0x00007f54c1b7bc06 in gc_finalize (L=0x41b5c378) at lj_gc.c:518

#5 0x00007f54c1b7c488 in lj_gc_finalize_udata (L=0x41b5c378) at lj_gc.c:525

#6 0x00007f54c1b81e81 in cpfinalize (L=0x41b5c378, dummy=<value optimized out>, ud=<value optimized out>) at lj_state.c:229

#7 0x00007f54c1b7916c in lj_vm_cpcall () from /opt/nginx/libs/libluajit-5.1.so.2

#8 0x00007f54c1b81e3d in lua_close (L=0x41b5c378) at lj_state.c:251

#9 0x0000000000484a11 in ngx_http_lua_cleanup_vm (data="" optimized out>) at ../lua-nginx-module/src/ngx_http_lua_module.c:667

#10 0x00000000004118e9 in ngx_destroy_pool (pool=0x22d5f40) at src/core/ngx_palloc.c:55

#11 0x000000000042db02 in ngx_worker_process_exit (cycle=0x22d5f90) at src/os/unix/ngx_process_cycle.c:1067

#12 0x000000000042dc65 in ngx_worker_process_cycle (cycle=0x22d5f90, data="" optimized out>) at src/os/unix/ngx_process_cycle.c:812

#13 0x000000000042c3bc in ngx_spawn_process (cycle=0x22d5f90, proc=0x42db3a <ngx_worker_process_cycle>, data="" name=0x4b757b "worker process", respawn=1) at src/os/unix/ngx_process.c:198

#14 0x000000000042e649 in ngx_reap_children (cycle=0x22d5f90) at src/os/unix/ngx_process_cycle.c:619

#15 ngx_master_process_cycle (cycle=0x22d5f90) at src/os/unix/ngx_process_cycle.c:180

#16 0x0000000000410d9a in main (argc=<value optimized out>, argv=<value optimized out>) at src/core/nginx.c:412

nginx的版本为：nginx-1.3.11-RELEASE commit: e0235968fc75df45482929b0312dfd7a0b199520

lua module的版本为：commit: 1a52a5819def1f056a3c137a604f7a3398c812ef

kernel: 2.6.32-220.el6.x86_64

version: Red Hat Enterprise Linux Server release 6.2 (Santiago)

另外请问下，我写了个c module，通过valgrind测试报如下错误是不是正常的

==11073== Invalid read of size 4

==11073== at 0x4064D5: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40AB3A: lua_pushlstring (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x5D07D36: nessdb_get (nessdb.c:57)

==11073== by 0x41BF6A: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40BCFF: lua_pcall (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x404665: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40519C: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x41BF6A: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40BD91: lua_cpcall (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x403F83: main (in /usr/local/bin/luajit-2.0.0)

==11073== Address 0x5970094 is 4 bytes inside a block of size 7 alloc'd

==11073== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

==11073== by 0x5F0D55A: xcalloc (xmalloc.c:35)

==11073== by 0x5F10F8C: index_read_data (index.c:168)

==11073== by 0x5F11AA6: index_get (index.c:374)

==11073== by 0x5F133FC: db_get (db.c:46)

==11073== by 0x5D07CEF: nessdb_get (nessdb.c:54)

==11073== by 0x41BF6A: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40BCFF: lua_pcall (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x404665: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40519C: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x41BF6A: ??? (in /usr/local/bin/luajit-2.0.0)

==11073== by 0x40BD91: lua_cpcall (in /usr/local/bin/luajit-2.0.0)

==11073==

best wishes, ASAP...

agentzh

Hello!

On Thu, Jan 17, 2013 at 2:21 AM, tiger yang wrote:
> 在使用nginx lua module的时候，突然爆出来一个core dump。bt的信息如下：
> #0  0x0000000000006d1e in ?? ()
> #1  0x00007f54c1bc4b92 in lj_cf_package_unloadlib (L=<value optimized out>)
> at lib_package.c:258
> #2  0x00007f54c1b78e2b in lj_BC_FUNCC () from
> /opt/nginx/libs/libluajit-5.1.so.2
>

从 backtrace 看是在 nginx worker 进程退出关闭 Lua VM 时发生的崩溃。这倒并不会影响用户请求，但还是指示了某个地方存在问题。

1. 你使用的是什么版本的 LuaJIT 2.0?
2. 你是否使用了第三方的（包括你自己的） Lua C 库？
3. 你能否提供一个能复现此问题的最小化的完整示例？

> nginx的版本为：nginx-1.3.11-RELEASE                          commit:
> e0235968fc75df45482929b0312dfd7a0b199520

ngx_lua 与 nginx 1.3.9 及其以后版本（暂时）存在已知的兼容性问题。建议使用 1.3.8 或之前的版本（或者 1.2.6 稳定版）。

>
> 另外请问下，我写了个c module，通过valgrind测试报如下错误是不是正常的
> ==11073== Invalid read of size 4
> ==11073==    at 0x4064D5: ??? (in /usr/local/bin/luajit-2.0.0)
> ==11073==    by 0x40AB3A: lua_pushlstring (in /usr/local/bin/luajit-2.0.0)

这个警告有可能是无害的，你需要进一步进行确认。

另外，建议尽量使用 LuaJIT 的 FFI 来粘合 C 代码，而不是传统的 Lua C 模块的形式。

Best regards,
-agentzh

believe3301

我知道为啥core dump，我在nginx运行过程中，把luajit加了-g选项重新编译了下，然后在重启nginx就会发生core dump。

为啥推荐使用luajit ffi的方式呢？

在 2013年1月18日上午3:06，agentzh <age...@gmail.com>写道：

Hello!

On Thu, Jan 17, 2013 at 2:21 AM, tiger yang wrote:
> 在使用nginx lua module的时候，突然爆出来一个core dump。bt的信息如下：
> #0 0x0000000000006d1e in ?? ()
> #1 0x00007f54c1bc4b92 in lj_cf_package_unloadlib (L=<value optimized out>)
> at lib_package.c:258
> #2 0x00007f54c1b78e2b in lj_BC_FUNCC () from
> /opt/nginx/libs/libluajit-5.1.so.2
>

从 backtrace 看是在 nginx worker 进程退出关闭 Lua VM 时发生的崩溃。这倒并不会影响用户请求，但还是指示了某个地方存在问题。

1. 你使用的是什么版本的 LuaJIT 2.0?
2. 你是否使用了第三方的（包括你自己的） Lua C 库？
3. 你能否提供一个能复现此问题的最小化的完整示例？

> nginx的版本为：nginx-1.3.11-RELEASE commit:
> e0235968fc75df45482929b0312dfd7a0b199520

ngx_lua 与 nginx 1.3.9 及其以后版本（暂时）存在已知的兼容性问题。建议使用 1.3.8 或之前的版本（或者 1.2.6 稳定版）。

>
> 另外请问下，我写了个c module，通过valgrind测试报如下错误是不是正常的
> ==11073== Invalid read of size 4
> ==11073== at 0x4064D5: ??? (in /usr/local/bin/luajit-2.0.0)
> ==11073== by 0x40AB3A: lua_pushlstring (in /usr/local/bin/luajit-2.0.0)

这个警告有可能是无害的，你需要进一步进行确认。

另外，建议尽量使用 LuaJIT 的 FFI 来粘合 C 代码，而不是传统的 Lua C 模块的形式。

Best regards,
-agentzh

agentzh

Hello!

2013/1/17 tg.yang:
> 我知道为啥core dump，我在nginx运行过程中，把luajit加了-g选项重新编译了下，然后在重启nginx就会发生core dump。
>

好吧。。。你是具体用什么方式“重启” nginx 的？

> 为啥推荐使用luajit ffi的方式呢？
>

因为

1. FFI 在使用上比传统 Lua C 模块方便很多，不用写一行自己的 C 代码；

2. FFI 可以和 LuaJIT 2.0 的 JIT compiler 一起工作。如果你使用传统的 Lua C 模块，则使用该 Lua C
模块的所有相关的 Lua 代码都只能在 LuaJIT 2.0 中以解释方式执行了（即永远不会被 JIT 编译为机器代码）。

Best regards,
-agentzh

P.S. 抄送 openresty 中文邮件列表。

believe3301

简单粗暴的重启方式，直接kill master进程，然后将nginx启动。

顺便咨询个问题，我抓包发现nginx在连接建立5s后客户端发送了请求，可是nginx直接发rst包把连接给掐了。请求比较小，才70byte，而且对timeout都没啥设置。

可惜抓包的数据都被我删除了。

祝买票顺利。。。。。。。。。。。

在米国不用迁徙了吧。。

在 2013年1月18日上午10:54，agentzh <age...@gmail.com>写道：

Hello!

2013/1/17 tg.yang:

> 我知道为啥core dump，我在nginx运行过程中，把luajit加了-g选项重新编译了下，然后在重启nginx就会发生core dump。
>

好吧。。。你是具体用什么方式“重启” nginx 的？

> 为啥推荐使用luajit ffi的方式呢？
>

因为

1. FFI 在使用上比传统 Lua C 模块方便很多，不用写一行自己的 C 代码；

2. FFI 可以和 LuaJIT 2.0 的 JIT compiler 一起工作。如果你使用传统的 Lua C 模块，则使用该 Lua C
模块的所有相关的 Lua 代码都只能在 LuaJIT 2.0 中以解释方式执行了（即永远不会被 JIT 编译为机器代码）。

Best regards,
-agentzh

P.S. 抄送 openresty 中文邮件列表。