lua-cjson 动态库变化的时候导致SIGSEGV

ywsample · 2014-08-17T23:53:09+00:00

非常感谢!On Monday, August 18, 2014 6:01:57 AM UTC+8, agentzh wrote:Hello! 2014-08-17 0:23 GMT-07:00 aaashun: > 本&#x546...

lua-cjson 动态库变化的时候导致SIGSEGV

ywsample

hi, agentzh

今天跑一个程序的时候，无意中发现当cjson.so动态库变化后，会导致再次请求产生SIGSEGV信号

大概是这样的
配置：
location /test {
content_by_lua '
local cjson = require "cjson"

local b = cjson.encode({a = 1, b = 2})

';
}

当我第一个次请求 test的时候，没有什么异常，但是如果这个时候把lualib下的cjson.so替换掉(没有重新编译openresty，只是把build/lua-cjson-2.1.0.1/cjson.so拷贝到lualib下，这个时候再次请求test，就会导致worker产生SIGSEGV信号退出

请教下春哥，这个是期望的行为吗？

我测试了ngx_openresty-1.5.8.1之前的版本不会出现这个问题，但是之后的版本会出现这个问题，我大概看了下lua-cjson的代码，之前的版本config是放在register中的，而之后的版本则放到了upvalue中了，会是这个影响的吗？

ywsample :)

agentzh

Hello!

2014-08-17 8:53 GMT-07:00 ywsample:
> 当我第一个次请求
> test的时候，没有什么异常，但是如果这个时候把lualib下的cjson.so替换掉(没有重新编译openresty，只是把build/lua-cjson-2.1.0.1/cjson.so拷贝到lualib下，这个时候再次请求test，就会导致worker产生SIGSEGV信号退出
>

很奇怪的是，require() 有缓冲已加载 Lua 模块的行为（在 VM 级别的 package.loaded 表中），所以当 cjson
模块通过第一个请求加载之后，后续请求不应触发重复加载。

难道你关闭了 lua_code_cache? 如果真的禁用 lua_code_cache 话，则会导致两个彼此不兼容的 (cjson)
DSO 被加载进同一个进程空间，出现不可预期的行为。毕竟 lua_code_cache off 并没有设计成在生产上使用，所以无所谓了。

Regards,
-agentzh

ywsample

hello

>难道你关闭了 lua_code_cache? 如果真的禁用 lua_code_cache 话，则会导致两个彼此不兼容的 (cjson)
>DSO 被加载进同一个进程空间，出现不可预期的行为。毕竟 lua_code_cache off 并没有设计成在生产上使用，所以无所谓了。

我应该给个完整的配置的，不好意思
如下配置
worker_processes 1;
error_log logs/error.log warn;
user root;
events {
    use epoll;
}
http {
    server {
        listen 8002;
        location /test {
            content_by_lua '
                local cjson = require "cjson"
                local c = cjson.encode({a = 1, b = 2})
            ';
        }
    }
}

1, 第一次编译openresty-1.7.2.1 (./configure --prefix=XXX --with-cc-opt='-O0' -j4) 完测试， curl localhost:8002/test，没有问题
2, 重新执行make install之后，再次curl localhost:8002/test(期间nginx不重启)，就出现SIGSEGV信号了

3, 之后再次请求就请求又正常了，但是重复2的步骤又会出现同样的问题

在 2014年8月18日上午3:24，Yichun Zhang (agentzh) <age...@gmail.com>写道：

Hello!

2014-08-17 8:53 GMT-07:00 ywsample:

> 当我第一个次请求
> test的时候，没有什么异常，但是如果这个时候把lualib下的cjson.so替换掉(没有重新编译openresty，只是把build/lua-cjson-2.1.0.1/cjson.so拷贝到lualib下，这个时候再次请求test，就会导致worker产生SIGSEGV信号退出
>

很奇怪的是，require() 有缓冲已加载 Lua 模块的行为（在 VM 级别的 package.loaded 表中），所以当 cjson
模块通过第一个请求加载之后，后续请求不应触发重复加载。

难道你关闭了 lua_code_cache? 如果真的禁用 lua_code_cache 话，则会导致两个彼此不兼容的 (cjson)
DSO 被加载进同一个进程空间，出现不可预期的行为。毕竟 lua_code_cache off 并没有设计成在生产上使用，所以无所谓了。

Regards,
-agentzh

--

ywsample :)

agentzh

Hello!

2014-08-17 19:22 GMT-07:00 ywsample:
> 1, 第一次编译openresty-1.7.2.1 (./configure --prefix=XXX --with-cc-opt='-O0' -j4)
> 完测试， curl localhost:8002/test，没有问题
> 2, 重新执行make install之后，再次curl localhost:8002/test(期间nginx不重启)，就出现SIGSEGV信号了
> 3, 之后再次请求就请求又正常了，但是重复2的步骤又会出现同样的问题
>

多谢你提供的复现步骤！我检查了一下，确实是新版 lua-cjson 里的一个 bug，即它的 Makefile 里在安装 cjson.so
时单纯使用了 cp 命令直接对已有的 cjson.so 进行了改写，而原先的 cjson.so
已经被正在运行的可执行文件加载和映射，直接就地改写原文件会导致不可预期的结果（比如 core dump）。正确的做法是先 rm（或
unlink），再进行 cp. OpenResty 1.5.8.1 中包含的老版本的 lua-cjson 则是使用的是 install
命令，它总是会先 unlink 老文件再行创建新文件，所以不会出现问题。

稍后我会提交一个补丁修复一下这个问题，多谢报告！

Regards,
-agentzh

agentzh

Hello!

2014-08-17 22:02 GMT-07:00 Yichun Zhang (agentzh):
>
> 稍后我会提交一个补丁修复一下这个问题，多谢报告！
>

已修正：

   https://github.com/openresty/lua-cjson/commit/8ed5ea55

这将会包含在下一个 openresty 发布中。

多谢！
-agentzh