Re: 春哥你好，弱弱的问一下 lua_ignore_client_abort off 配置指令在你 to do list 里的什么位置

agentzh · 2012-11-12T13:28:41+00:00

多谢春哥~ 期待ing~ 在 27 Oct, 2012，13:51，agentzh <age...@gmail.com> 写道：...

Re: 春哥你好，弱弱的问一下 lua_ignore_client_abort off 配置指令在你 to do list 里的什么位置

agentzh

Hello!

2012/10/26 朱德江:
>     还有一个主要问题就是不能精确统计某个页面的关闭时间
>     目前想到的是能统计粗略的关闭时间，就是某页面最后一次向聊天server发请求的时间，这个时间存在40秒的误差（blpop是40s超时）
>
>     所以特意来问问lua_ignore_client_abort off 配置指令在你 to do list 里的什么位置
>

lua_check_client_abort 和 ngx.on_abort() 这两个新功能刚刚都已包含在了 ngx_lua 0.7.4 和
ngx_openresty 1.2.4.7 发布中：

    http://openresty.org/#Download

相关的文档在这里：

    http://wiki.nginx.org/HttpLuaModule#lua_check_client_abort
    http://wiki.nginx.org/HttpLuaModule#ngx.on_abort

你可以把 lua_check_client_abort 置为 on，同时通过 ngx.on_abort()
注册一个回调函数，然后在回调函数里面记录当前时间，并通过 lua-resty-* 库更新到你的后端存储（比如
redis），并请在回调函数的末尾通过 ngx.exit(499) 终止当前请求（如果你在回调里不这么做，则当前请求还会照常执行下去）。

有了 on_abort 回调，你就不必在 log_by_lua 里面搞了，嘿嘿。

欢迎反馈结果 :)

Best regards,
-agentzh

P.S. 同时抄送给 openresty 邮件组。

doujiang24

春哥，你好

在使用ngx.on_abort 的时候碰到以下错误：
2012/11/23 18:36:26 [alert] 6001#0: worker process 6006 exited on signal 11

最小复现案例代码如下：
当请求执行10秒以上，浏览器中断触发abort会报错

local redis = require "resty.redis"

local function my_cleanup()
    ngx.exit(499)
end

local ok, err = ngx.on_abort(my_cleanup)
if not ok then
    ngx.log(ngx.ERR, "failed to register the on_abort callback: ", err)
    ngx.exit(500)
end

local red = redis:new()
red:set_timeout(60000) -- 60 sec
local ok, err = red:connect("127.0.0.1", "6400")

if not ok then
    ngx.log(ngx.ERR, "failed to connect: ", err)
    ngx.exit(500)
end

local res, err = red:blpop("not_exists", 40)

ngx.say('ok')

版本：1.2.4.7

最新的9里面也有这样的报错，只是不那么容易出现

麻烦春哥帮忙看看，多谢





在 12 Nov, 2012，13:28，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> 2012/10/26 朱德江:
>>    还有一个主要问题就是不能精确统计某个页面的关闭时间
>>    目前想到的是能统计粗略的关闭时间，就是某页面最后一次向聊天server发请求的时间，这个时间存在40秒的误差（blpop是40s超时）
>> 
>>    所以特意来问问lua_ignore_client_abort off 配置指令在你 to do list 里的什么位置
>> 
> 
> lua_check_client_abort 和 ngx.on_abort() 这两个新功能刚刚都已包含在了 ngx_lua 0.7.4 和
> ngx_openresty 1.2.4.7 发布中：
> 
>    http://openresty.org/#Download
> 
> 相关的文档在这里：
> 
>    http://wiki.nginx.org/HttpLuaModule#lua_check_client_abort
>    http://wiki.nginx.org/HttpLuaModule#ngx.on_abort
> 
> 你可以把 lua_check_client_abort 置为 on，同时通过 ngx.on_abort()
> 注册一个回调函数，然后在回调函数里面记录当前时间，并通过 lua-resty-* 库更新到你的后端存储（比如
> redis），并请在回调函数的末尾通过 ngx.exit(499) 终止当前请求（如果你在回调里不这么做，则当前请求还会照常执行下去）。
> 
> 有了 on_abort 回调，你就不必在 log_by_lua 里面搞了，嘿嘿。
> 
> 欢迎反馈结果 :)
> 
> Best regards,
> -agentzh
> 
> P.S. 同时抄送给 openresty 邮件组。
> 
>

agentzh

Hello!

2012/11/23 Goujiang:
> 在使用ngx.on_abort 的时候碰到以下错误：
> 2012/11/23 18:36:26 [alert] 6001#0: worker process 6006 exited on signal 11
>

signal 11 是 segmentation fault，你能使用 gdb 这样的工具得到对应的 nginx worker 进程崩溃发生时的堆栈轨迹吗？

另外，能否提供你的操作系统种类？比如是 Linux x86_64 还是其他？

你使用的 openresty 的 nginx 可执行文件的 -V 选项输出是怎样的？即命令

     /path/to/openresty/nginx/sbin/nginx -V

> 最小复现案例代码如下：
> 当请求执行10秒以上，浏览器中断触发abort会报错
>

我按照你说的步骤在 Linux x86_64 上使用 ngx_openresty 1.2.4.7 运行你的用例，无法复现任何问题。使用
ngx_openresty 1.2.4.9 亦是如此。

另外，如果可能的话，建议你使用 valgrind 的 memcheck 工具运行你的 nginx 并禁用nginx 的 daemon 模式和
master_process. 看看 valgrind 是否可以捕捉到第一时间的内存非法读写。

多谢报告！但显然我需要更多的信息以便我能复现你看到的问题 :)

Best regards,
-agentzh

doujiang24

这些工具都没用过，学学去~

-V的输出：
nginx version: ngx_openresty/1.2.4.9
built by gcc 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
TLS SNI support enabled
configure arguments: --prefix=/opt/openresty/nginx --add-module=../ngx_devel_kit-0.2.17 --add-module=../iconv-nginx-module-0.10rc7 --add-module=../echo-nginx-module-0.41 --add-module=../xss-nginx-module-0.03rc9 --add-module=../ngx_coolkit-0.2rc1 --add-module=../set-misc-nginx-module-0.22rc8 --add-module=../form-input-nginx-module-0.07rc5 --add-module=../encrypted-session-nginx-module-0.02 --add-module=../drizzle-nginx-module-0.1.4 --add-module=../ngx_postgres-1.0rc2 --add-module=../srcache-nginx-module-0.16 --add-module=../ngx_lua-0.7.5 --add-module=../headers-more-nginx-module-0.19 --add-module=../array-var-nginx-module-0.03rc1 --add-module=../memc-nginx-module-0.13rc3 --add-module=../redis2-nginx-module-0.09 --add-module=../redis-nginx-module-0.3.6 --add-module=../auth-request-nginx-module-0.2 --add-module=../rds-json-nginx-module-0.12rc10 --add-module=../rds-csv-nginx-module-0.05rc2 --with-ld-opt=-Wl,-rpath,/opt/libs/libdrizzle/lib:/opt/openresty/luajit/lib --with-http_ssl_module

Linux 2.6.35-22-generic #35-Ubuntu 2010 i686 GNU/Linux

多谢春哥~

ps：web版gmail被墙了，真不方便

在 24 Nov, 2012，9:17，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> 2012/11/23 Goujiang:
>> 在使用ngx.on_abort 的时候碰到以下错误：
>> 2012/11/23 18:36:26 [alert] 6001#0: worker process 6006 exited on signal 11
>> 
> 
> signal 11 是 segmentation fault，你能使用 gdb 这样的工具得到对应的 nginx worker 进程崩溃发生时的堆栈轨迹吗？
> 
> 另外，能否提供你的操作系统种类？比如是 Linux x86_64 还是其他？
> 
> 你使用的 openresty 的 nginx 可执行文件的 -V 选项输出是怎样的？即命令
> 
>     /path/to/openresty/nginx/sbin/nginx -V
> 
>> 最小复现案例代码如下：
>> 当请求执行10秒以上，浏览器中断触发abort会报错
>> 
> 
> 我按照你说的步骤在 Linux x86_64 上使用 ngx_openresty 1.2.4.7 运行你的用例，无法复现任何问题。使用
> ngx_openresty 1.2.4.9 亦是如此。
> 
> 另外，如果可能的话，建议你使用 valgrind 的 memcheck 工具运行你的 nginx 并禁用nginx 的 daemon 模式和
> master_process. 看看 valgrind 是否可以捕捉到第一时间的内存非法读写。
> 
> 多谢报告！但显然我需要更多的信息以便我能复现你看到的问题 :)
> 
> Best regards,
> -agentzh
> 
>

agentzh

Hello!

2012/11/26 Goujiang:
> 这些工具都没用过，学学去~
>

其实很简单的。在这里我不妨简单介绍一下 :)

使用 gdb 调试崩溃的基本步骤：

1. 在 nginx.conf 中配置 worker_processes 1;
2. 启动 nginx 之后，用 ps 命令得到唯一的 nginx worker 进程的 pid，比如是 1234（注意不是 nginx
master 进程！）；
3. 在一个终端中使用 gdb -p 1234 命令，将 gdb 绑定到那个 nginx worker 进程上去，此时会出现 (gdb)
提示符（如果你运行 nginx worker 进程的帐户名和当前帐户名不相同，你可能需要在这里 sudo 一下）；
4. 在 (gdb) 提示符后输入命令 c，即 continue；
5. 在浏览器中正常访问你的问题接口，复现问题。当 nginx worker 进程崩溃时，(gdb) 提示符会再次出现；
6. 在 (gdb) 提示符后输入 bt full 命令，得到崩溃发生位置上的完整的堆栈轨迹。将 gdb continue 命令之后的所有输出都复制到邮件中来。

使用 Valgrind memcheck 调试的基本步骤：

1. 在 nginx.conf 中进行如下配置：

    daemon off;
    master_process off;
    worker_processes 1;

2. 将 ngx_lua 模块中的 valgrind.suppress 文件复制到你本地：

    wget http://raw.github.com/chaoslawful/lua-nginx-module/master/valgrind.suppress
-O /tmp/valgrind.suppress

2. 使用 valgrind 启动 nginx，并指定步骤 2 中下载的 valgrind.suppress 文件：

    valgrind --suppressions=/tmp/valgrind.suppress \
           --leak-check=full \
          /path/to/nginx/sbin/nginx -p /path/to/server/root/

这里假设你平时都是通过命令

    /path/to/nginx/sbin/nginx -p /path/to/server/root/

启动 nginx 的。而现在我们是让 valgrind 这个虚拟机替我们启动 nginx. 启动后我们应当会看到类似下面的输出：

    ==3023== Memcheck, a memory error detector
    ==3023== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
    ==3023== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
    ==3023== Command: ./work/nginx/sbin/nginx -p
/home/agentzh/git/lua-nginx-module/t/servroot/
    ==3023==

3. 在浏览器中正常访问你的服务，直至问题复现；此时 valgrind 会打印出相应的内存非法读写的错误信息（如果有的话）。

4. 使用 ps 命令得到 valgrind 进程的 pid，假设为 5678，然后使用下面命令让其优雅退出：

    kill -QUIT 5678

这里你可能需要使用 sudo，如果权限不足的话。

5. 将 valgrind 的所有输出都复制到邮件中来。（如果输出已经刷屏了话，你可以事先在步骤 2 中把 valgrind 的
stdout 和 stderr 输出都重定向到某个文件。）

> Linux 2.6.35-22-generic #35-Ubuntu 2010 i686 GNU/Linux
>

哦，原来是 32 位的系统。呵呵。

Best regards,
-agentzh

> ps：web版gmail被墙了，真不方便

找一个靠谱的翻墙 VPN 吧。。。呵呵。或者也可以尝试在 /etc/hosts 文件中直接绑定 Google 中国服务器的 IP 地址。

kindy61

春哥，

我用类似代码在 ngx_openresty 1.2.4.9 下测试，发现如果 on_abort 时，如果已经输出了内容，那么 on_abort 线程会出错退出，主请求仍然会继续执行。。

也许 ngx.exit(499) 不是个结束主请求的好方法。

2012/11/24 agentzh <age...@gmail.com>

Hello!

2012/11/23 Goujiang:

> 在使用ngx.on_abort 的时候碰到以下错误：
> 2012/11/23 18:36:26 [alert] 6001#0: worker process 6006 exited on signal 11
>

signal 11 是 segmentation fault，你能使用 gdb 这样的工具得到对应的 nginx worker 进程崩溃发生时的堆栈轨迹吗？

另外，能否提供你的操作系统种类？比如是 Linux x86_64 还是其他？

你使用的 openresty 的 nginx 可执行文件的 -V 选项输出是怎样的？即命令

/path/to/openresty/nginx/sbin/nginx -V

> 最小复现案例代码如下：
> 当请求执行10秒以上，浏览器中断触发abort会报错
>

我按照你说的步骤在 Linux x86_64 上使用 ngx_openresty 1.2.4.7 运行你的用例，无法复现任何问题。使用
ngx_openresty 1.2.4.9 亦是如此。

另外，如果可能的话，建议你使用 valgrind 的 memcheck 工具运行你的 nginx 并禁用nginx 的 daemon 模式和
master_process. 看看 valgrind 是否可以捕捉到第一时间的内存非法读写。

多谢报告！但显然我需要更多的信息以便我能复现你看到的问题 :)

Best regards,
-agentzh

--
- - - - - - - - - - - -
林青(Kindy Lin)

agentzh

Hello!

2012/11/26 kindy:
> 我用类似代码在 ngx_openresty 1.2.4.9 下测试，发现如果 on_abort 时，如果已经输出了内容，那么 on_abort
> 线程会出错退出，主请求仍然会继续执行。。
> 也许 ngx.exit(499) 不是个结束主请求的好方法。
>

ngx.exit(499) 在这里是正确的用法。之所以你试了不成是因为 ngx.exit() 没有对 499, 408 和 444 进行特殊处理 ;)

我刚刚提交了下面这个补丁，对这个问题进行修正（同时添加了相应的测试用例）：

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

Thanks!
-agentzh

doujiang24

多谢春哥热心详细的指导^_^

尝试了gdb，得到如下，貌似堆栈轨迹不完整呢
我在浏览器端四五个请求并行测试的（单个请求测试的时候不容易出现），是不是因为这个原因导致不完整呢

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00539f75 in lj_str_new () from /opt/openresty/luajit/lib/libluajit-5.1.so.2
(gdb) bt full
#0  0x00539f75 in lj_str_new () from /opt/openresty/luajit/lib/libluajit-5.1.so.2
No symbol table info available.
#1  0x08271a64 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

valgrind在我这机器上安装出了点问题，下回再试试

在 27 Nov, 2012，3:11，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> 2012/11/26 Goujiang:
>> 这些工具都没用过，学学去~
>> 
> 
> 其实很简单的。在这里我不妨简单介绍一下 :)
> 
> 使用 gdb 调试崩溃的基本步骤：
> 
> 1. 在 nginx.conf 中配置 worker_processes 1;
> 2. 启动 nginx 之后，用 ps 命令得到唯一的 nginx worker 进程的 pid，比如是 1234（注意不是 nginx
> master 进程！）；
> 3. 在一个终端中使用 gdb -p 1234 命令，将 gdb 绑定到那个 nginx worker 进程上去，此时会出现 (gdb)
> 提示符（如果你运行 nginx worker 进程的帐户名和当前帐户名不相同，你可能需要在这里 sudo 一下）；
> 4. 在 (gdb) 提示符后输入命令 c，即 continue；
> 5. 在浏览器中正常访问你的问题接口，复现问题。当 nginx worker 进程崩溃时，(gdb) 提示符会再次出现；
> 6. 在 (gdb) 提示符后输入 bt full 命令，得到崩溃发生位置上的完整的堆栈轨迹。将 gdb continue 命令之后的所有输出都复制到邮件中来。
> 
> 使用 Valgrind memcheck 调试的基本步骤：
> 
> 1. 在 nginx.conf 中进行如下配置：
> 
>    daemon off;
>    master_process off;
>    worker_processes 1;
> 
> 2. 将 ngx_lua 模块中的 valgrind.suppress 文件复制到你本地：
> 
>    wget http://raw.github.com/chaoslawful/lua-nginx-module/master/valgrind.suppress
> -O /tmp/valgrind.suppress
> 
> 2. 使用 valgrind 启动 nginx，并指定步骤 2 中下载的 valgrind.suppress 文件：
> 
>    valgrind --suppressions=/tmp/valgrind.suppress \
>           --leak-check=full \
>          /path/to/nginx/sbin/nginx -p /path/to/server/root/
> 
> 这里假设你平时都是通过命令
> 
>    /path/to/nginx/sbin/nginx -p /path/to/server/root/
> 
> 启动 nginx 的。而现在我们是让 valgrind 这个虚拟机替我们启动 nginx. 启动后我们应当会看到类似下面的输出：
> 
>    ==3023== Memcheck, a memory error detector
>    ==3023== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
>    ==3023== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
>    ==3023== Command: ./work/nginx/sbin/nginx -p
> /home/agentzh/git/lua-nginx-module/t/servroot/
>    ==3023==
> 
> 3. 在浏览器中正常访问你的服务，直至问题复现；此时 valgrind 会打印出相应的内存非法读写的错误信息（如果有的话）。
> 
> 4. 使用 ps 命令得到 valgrind 进程的 pid，假设为 5678，然后使用下面命令让其优雅退出：
> 
>    kill -QUIT 5678
> 
> 这里你可能需要使用 sudo，如果权限不足的话。
> 
> 5. 将 valgrind 的所有输出都复制到邮件中来。（如果输出已经刷屏了话，你可以事先在步骤 2 中把 valgrind 的
> stdout 和 stderr 输出都重定向到某个文件。）
> 
>> Linux 2.6.35-22-generic #35-Ubuntu 2010 i686 GNU/Linux
>> 
> 
> 哦，原来是 32 位的系统。呵呵。
> 
> Best regards,
> -agentzh
> 
>> ps：web版gmail被墙了，真不方便
> 
> 找一个靠谱的翻墙 VPN 吧。。。呵呵。或者也可以尝试在 /etc/hosts 文件中直接绑定 Google 中国服务器的 IP 地址。
> 
>

agentzh

Hello!

2012/11/28 Goujiang:
> 尝试了gdb，得到如下，貌似堆栈轨迹不完整呢
> 我在浏览器端四五个请求并行测试的（单个请求测试的时候不容易出现），是不是因为这个原因导致不完整呢
>

Okay，我今天在 Amazon EC2 上启了一个 Linux i386 的系统，终于在上面通过下面这个最小化的用例复现了你报告中的这个崩溃问题：

    lua_check_client_abort on;

    location = /main {
        echo_location_async /proxy;
        echo_location_async /proxy;
        echo_location_async /proxy;
        echo_location_async /proxy;
        echo_location_async /proxy;
        echo_location_async /proxy;
    }

    location = /proxy {
        proxy_send_timeout   6s;
        proxy_read_timeout   6s;
        proxy_pass http://127.0.0.1:$server_port/t;
    }

    location = /t {
        content_by_lua '
            local redis = require "resty.redis"

            local function my_cleanup()
                ngx.exit(499)
            end

            local ok, err = ngx.on_abort(my_cleanup)
            if not ok then
                ngx.log(ngx.ERR, "failed to register the on_abort
callback: ", err)
                ngx.exit(500)
            end

            local red = redis:new()
            red:set_timeout(60000) -- 60 sec
            local ok, err = red:connect("127.0.0.1", 6379)

            if not ok then
                ngx.log(ngx.ERR, "failed to connect: ", err)
                ngx.exit(500)
            end

            local res, err = red:blpop("not_exists", 40)

            ngx.say("ok")
        ';
    }

访问 location /main 时，nginx 进程便会发生崩溃。使用 gdb 可以得到下面的输出：

    Program received signal SIGSEGV, Segmentation fault.
    0xb76b3a45 in lj_str_new (L=0xb70d23a0, str=0xb771702f "cannot
resume non-suspended coroutine", lenx=37) at lj_str.c:123
    123	  o = gcref(g->strhash[h & g->strmask]);
    (gdb) bt
    #0  0xb76b3a45 in lj_str_new (L=0xb70d23a0, str=0xb771702f "cannot
resume non-suspended coroutine", lenx=37) at lj_str.c:123
    #1  0xb76b2a8c in lj_err_str (L=0xb70d23a0, em=LJ_ERR_COSUSP) at
lj_err.c:480
    #2  0xb76c08f1 in lua_resume (L=0xb70d23a0, nargs=0) at lj_api.c:1136
    #3  0x080e9e7d in ngx_http_lua_run_thread (L=0xb70bd1c0,
r=0x8711378, ctx=0x8712070, nret=0)
        at /home/ec2-user/git/lua-nginx-module/src/ngx_http_lua_util.c:1019
    #4  0x080eb14e in ngx_http_lua_on_abort_resume (r=0x8711378)
        at /home/ec2-user/git/lua-nginx-module/src/ngx_http_lua_util.c:3197
    #5  0x080ebf95 in ngx_http_lua_content_wev_handler (r=0x8711378)
        at /home/ec2-user/git/lua-nginx-module/src/ngx_http_lua_contentby.c:128
    #6  0x080eb4ac in ngx_http_lua_rd_check_broken_connection (r=0x8711378)
        at /home/ec2-user/git/lua-nginx-module/src/ngx_http_lua_util.c:3167
    #7  0x0808bc0c in ngx_http_request_handler (ev=0x86f47c0) at
src/http/ngx_http_request.c:1873
    #8  0x08079bed in ngx_epoll_process_events (cycle=0x86c36e8,
timer=53996, flags=1) at src/event/modules/ngx_epoll_module.c:683
    #9  0x0806f9bd in ngx_process_events_and_timers (cycle=0x86c36e8)
at src/event/ngx_event.c:247
    #10 0x080781d8 in ngx_single_process_cycle (cycle=0x86c36e8) at
src/os/unix/ngx_process_cycle.c:316
    #11 0x0805a6cb in main (argc=5, argv=0xbffecc74) at src/core/nginx.c:407

如果使用 valgrind memcheck 运行 nginx，得到的第一个报错也是此位置：

    ==9744== Invalid read of size 4
    ==9744==    at 0x4053A45: lj_str_new (lj_str.c:123)
    ==9744==    by 0x4052A8B: lj_err_str (lj_err.c:480)
    ==9744==    by 0x40608F0: lua_resume (lj_api.c:1136)
    ==9744==    by 0x80E9E7C: ngx_http_lua_run_thread (ngx_http_lua_util.c:1019)
    ==9744==    by 0x80EB14D: ngx_http_lua_on_abort_resume
(ngx_http_lua_util.c:3197)
    ==9744==    by 0x80EBF94: ngx_http_lua_content_wev_handler
(ngx_http_lua_contentby.c:128)
    ==9744==    by 0x80EB4AB: ngx_http_lua_rd_check_broken_connection
(ngx_http_lua_util.c:3167)
    ==9744==    by 0x808BC0B: ngx_http_request_handler (ngx_http_request.c:1873)
    ==9744==    by 0x8079BEC: ngx_epoll_process_events (ngx_epoll_module.c:683)
    ==9744==    by 0x806F9BC: ngx_process_events_and_timers (ngx_event.c:247)
    ==9744==    by 0x80781D7: ngx_single_process_cycle (ngx_process_cycle.c:316)
    ==9744==    by 0x4372CE5: (below main) (in /lib/libc-2.12.so)
    ==9744==  Address 0x424 is not stack'd, malloc'd or (recently) free'd

有趣的是，同样的用例在 Linux x86_64 系统上是一切正常的。

现在既然可以可靠地复现问题了，修复也应该比较快了。多谢你的报告！

今天晚些时候如果成功修复的话，我会请你尝试新版本的，呵呵。

值得一提的是，为得到完整的堆栈轨迹，你需要启用 LuaJIT 的调试符号。最简单的做法是使用 --with-debug 重新编译
openresty（但此 --with-debug 选项不建议用于生产，因为会有较高的性能代价）。

Best regards,
-agentzh

agentzh

Hello!

On Fri, Nov 30, 2012 at 12:22 PM, agentzh wrote:
> 有趣的是，同样的用例在 Linux x86_64 系统上是一切正常的。
>
> 现在既然可以可靠地复现问题了，修复也应该比较快了。多谢你的报告！
>
> 今天晚些时候如果成功修复的话，我会请你尝试新版本的，呵呵。
>

经过几个小时的追踪，看起来倒像是 LuaJIT 2.0 自身的内存问题，到 on_wait 回调所在的 coroutine 被 resume
的时候就出错了，因其 status 竟变成了 183 这个非法的状态值（合法的状态值当为 0 ~ 3）。

同样的用例，同样的系统，使用标准 Lua 5.1.5 解释器就没有任何问题。使用用样的用例，在 Linux x86_64 系统上用
LuaJIT 2.0 运行也没有任何问题。

我看看能否将这个用例最小化后，提交给 Mike Pall 同学修复。如果真是 LuaJIT 2.0 内部的 bug，我现在还没本事自己修复，嘿嘿。

再次感谢你的报告！

Best regards,
-agentzh

doujiang24

多谢春哥详尽的解析，春哥的每次回答都是如此富有营养，让我等获益匪浅~

期待下一版本ing，再次感谢春哥~

在 1 Dec, 2012，9:42，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> On Fri, Nov 30, 2012 at 12:22 PM, agentzh wrote:
>> 有趣的是，同样的用例在 Linux x86_64 系统上是一切正常的。
>> 
>> 现在既然可以可靠地复现问题了，修复也应该比较快了。多谢你的报告！
>> 
>> 今天晚些时候如果成功修复的话，我会请你尝试新版本的，呵呵。
>> 
> 
> 经过几个小时的追踪，看起来倒像是 LuaJIT 2.0 自身的内存问题，到 on_wait 回调所在的 coroutine 被 resume
> 的时候就出错了，因其 status 竟变成了 183 这个非法的状态值（合法的状态值当为 0 ~ 3）。
> 
> 同样的用例，同样的系统，使用标准 Lua 5.1.5 解释器就没有任何问题。使用用样的用例，在 Linux x86_64 系统上用
> LuaJIT 2.0 运行也没有任何问题。
> 
> 我看看能否将这个用例最小化后，提交给 Mike Pall 同学修复。如果真是 LuaJIT 2.0 内部的 bug，我现在还没本事自己修复，嘿嘿。
> 
> 再次感谢你的报告！
> 
> Best regards,
> -agentzh
> 
>

agentzh

Hello!

2012/11/30 agentzh <age...@gmail.com>:
>
> 经过几个小时的追踪，看起来倒像是 LuaJIT 2.0 自身的内存问题，到 on_wait 回调所在的 coroutine 被 resume
> 的时候就出错了，因其 status 竟变成了 183 这个非法的状态值（合法的状态值当为 0 ~ 3）。
>

好吧，我错了。。。这并不是 LuaJIT 2.0 的问题，而是 ngx_lua 模块的 bug.

我已经把用例最小化到下面这个程度：

    location = /t {
        lua_check_client_abort on;
        content_by_lua '
            ngx.on_abort(function () end)
            collectgarbage()
            ngx.sleep(60)
        ';
    }

在 Linux i386 和 x86_64 上无论是使用 Lua 5.1.5 还是 LuaJIT 2.0.0，都能可靠地通过
Valgrind 捕捉到非法内存读写的问题。

其根本原因在于 ngx.on_abort() 创建的 Lua 协程对象没有被正确地注册到 Lua registry 中去，从而被 Lua
GC 提前回收了，从而再去 resume 它的时候便出现内存非法访问的问题了。

我刚刚已经提交了一个补丁修正了这个问题：

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

其实就是一个栈索引值写错了。。。汗。

由 ngx.thread.spawn() 创建的协程对象也有这个问题，下面这个例子也会出现内存非法访问：

    location /lua {
        content_by_lua '
            function f()
                ngx.sleep(0.1)
                ngx.say("f")
            end

            ngx.thread.spawn(f)
            collectgarbage()
        ';
    }

修正这个问题的补丁也几乎一模一样：

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

请在你那里尝试最新的 ngx_lua v0.7.6rc2:

    https://github.com/chaoslawful/lua-nginx-module/tags/

或者直接使用最新的 ngx_openresty 预发布版 1.2.4.11rc2:

    http://agentzh.org/misc/nginx/ngx_openresty-1.2.4.11rc2.tar.gz

Thanks!
-agentzh

doujiang24

我用最新版测试已经没有问题了，已经更新上线了，多谢春哥 ^_^

在 2 Dec, 2012，9:33，agentzh <age...@gmail.com> 写道：

> Hello!
> 
> 2012/11/30 agentzh <age...@gmail.com>:
>> 
>> 经过几个小时的追踪，看起来倒像是 LuaJIT 2.0 自身的内存问题，到 on_wait 回调所在的 coroutine 被 resume
>> 的时候就出错了，因其 status 竟变成了 183 这个非法的状态值（合法的状态值当为 0 ~ 3）。
>> 
> 
> 好吧，我错了。。。这并不是 LuaJIT 2.0 的问题，而是 ngx_lua 模块的 bug.
> 
> 我已经把用例最小化到下面这个程度：
> 
>    location = /t {
>        lua_check_client_abort on;
>        content_by_lua '
>            ngx.on_abort(function () end)
>            collectgarbage()
>            ngx.sleep(60)
>        ';
>    }
> 
> 在 Linux i386 和 x86_64 上无论是使用 Lua 5.1.5 还是 LuaJIT 2.0.0，都能可靠地通过
> Valgrind 捕捉到非法内存读写的问题。
> 
> 其根本原因在于 ngx.on_abort() 创建的 Lua 协程对象没有被正确地注册到 Lua registry 中去，从而被 Lua
> GC 提前回收了，从而再去 resume 它的时候便出现内存非法访问的问题了。
> 
> 我刚刚已经提交了一个补丁修正了这个问题：
> 
>    https://github.com/chaoslawful/lua-nginx-module/commit/7b0d7da
> 
> 其实就是一个栈索引值写错了。。。汗。
> 
> 由 ngx.thread.spawn() 创建的协程对象也有这个问题，下面这个例子也会出现内存非法访问：
> 
>    location /lua {
>        content_by_lua '
>            function f()
>                ngx.sleep(0.1)
>                ngx.say("f")
>            end
> 
>            ngx.thread.spawn(f)
>            collectgarbage()
>        ';
>    }
> 
> 修正这个问题的补丁也几乎一模一样：
> 
>    https://github.com/chaoslawful/lua-nginx-module/commit/ff1949b
> 
> 请在你那里尝试最新的 ngx_lua v0.7.6rc2:
> 
>    https://github.com/chaoslawful/lua-nginx-module/tags/
> 
> 或者直接使用最新的 ngx_openresty 预发布版 1.2.4.11rc2:
> 
>    http://agentzh.org/misc/nginx/ngx_openresty-1.2.4.11rc2.tar.gz
> 
> Thanks!
> -agentzh
> 
>