使用ngx.semaphore实现push后，nginx偶发crash，不知道什么原因。

oycwmail · 2016-04-08T10:59:30+00:00

太好了，是我想要的东东，正好我对 golang 略知&#x...

使用ngx.semaphore实现push后，nginx偶发crash，不知道什么原因。

oycwmail

最近在用openresty 1.9.7.3做push，之前的思路是

一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。

现在我尝试使用ngx.semaphore来优化push：

用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。

请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：

Core was generated by `nginx: worker process '.

Program terminated with signal 11, Segmentation fault.

#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)

at src/event/ngx_event_posted.c:31

31 ngx_delete_posted_event(ev);

(gdb) bt

#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)

at src/event/ngx_event_posted.c:31

#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259

#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753

#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">

name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198

#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)

at src/os/unix/ngx_process_cycle.c:358

#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243

#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359

(gdb) l

26 ev = ngx_queue_data(q, ngx_event_t, queue);

28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,

29 "posted event %p", ev);

31 ngx_delete_posted_event(ev);

33 ev->handler(ev);

34 }

35 }

(gdb) p *ev

$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,

complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,

posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,

handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,

right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,

next = 0x0}}

因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

oycwmail

#define ngx_delete_posted_event(ev) \

(ev)->posted = 0; \

ngx_queue_remove(&(ev)->queue); \

ngx_log_debug1(NGX_LOG_DEBUG_CORE, (ev)->log, 0, \

"delete posted event %p", ev);

#define ngx_queue_remove(x) \

(x)->next->prev = (x)->prev; \

(x)->prev->next = (x)->next

#endif

局部变量(ev)->queue= {prev = 0x7b03b0 <ngx_posted_events>, next = 0x0}}

看现场是(ev)->queue.next==0是引起ngx_queue_remove发生crash的直接原因，但为什么会这样却没有定位到。

在 2016年4月8日星期五 UTC+8上午10:59:30，oysoft写道：

最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。
低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

cuiweixie

项目只用到lua吗

cuiweixie

能提供最小的可重现用例吗

doujiang24

Hello,

在 2016年4月8日上午10:59，oysoft <oyc...@163.com>写道：

最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例

一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

oycwmail

多谢提醒，

我把semaphore全局池改成弱引用表，问题就解决了，

猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：

Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

doujiang24

Hello

在 2016年4月21日上午11:23，oysoft <oyc...@163.com>写道：

多谢提醒，
我把semaphore全局池改成弱引用表，问题就解决了，

猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

这个不应该的

你的全局表是什么结构呢，请求标识某种 string 为 key， semaphore instance 为 value ？

还有，你设置的 weak table 是 __mode = "kv" ?

semaphore 在被 gc 的时候，是有检查的，你可以检查错误日志来验证你的想法

https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_semaphore.c#L524

ps：是否有可复现的步骤描述呢，最好能去掉公司业务逻辑，这样方便公开讨论

或者，如果你不介意的话，可以单独发给我

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：
Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

--

oycwmail

全局表使用set，直接使用semaphore instance为key，

push_semaphore_set={}

添加下面代码就能解决问题。

setmetatable(push_semaphore_set, { __mode = "k" })

不添加，就偶发上面crash。

在 2016年4月23日星期六 UTC+8上午12:18:07，doujiang写道：

Hello

在 2016年4月21日上午11:23，oysoft <oycw...@163.com>写道：
多谢提醒，
我把semaphore全局池改成弱引用表，问题就解决了，
猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

这个不应该的
你的全局表是什么结构呢，请求标识某种 string 为 key， semaphore instance 为 value ？
还有，你设置的 weak table 是 __mode = "kv" ?

semaphore 在被 gc 的时候，是有检查的，你可以检查错误日志来验证你的想法
https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_semaphore.c#L524

ps：是否有可复现的步骤描述呢，最好能去掉公司业务逻辑，这样方便公开讨论
或者，如果你不介意的话，可以单独发给我

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：
Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

--

doujiang24

Hello,

在 2016年4月25日上午9:37，oysoft <oyc...@163.com>写道：

全局表使用set，直接使用semaphore instance为key，

push_semaphore_set={}

添加下面代码就能解决问题。

setmetatable(push_semaphore_set, { __mode = "k" })

你这个是让 semaphore instance 这个key 在全局表里为弱引用

这个不应该有影响的

你没有在请求退出的时候把全局表对应的的 semaphore 删掉？

是不是你还有其他的 C 模块逻辑依赖这个呢？

貌似，每次你提供的信息都不完整，靠猜真不好排除

始终觉得你现在的“解决办法“ 过于巧合，问题应该依然存在

不添加，就偶发上面crash。
在 2016年4月23日星期六 UTC+8上午12:18:07，doujiang写道：
Hello

在 2016年4月21日上午11:23，oysoft <oycw...@163.com>写道：
多谢提醒，
我把semaphore全局池改成弱引用表，问题就解决了，
猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

这个不应该的
你的全局表是什么结构呢，请求标识某种 string 为 key， semaphore instance 为 value ？
还有，你设置的 weak table 是 __mode = "kv" ?

semaphore 在被 gc 的时候，是有检查的，你可以检查错误日志来验证你的想法
https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_semaphore.c#L524

ps：是否有可复现的步骤描述呢，最好能去掉公司业务逻辑，这样方便公开讨论
或者，如果你不介意的话，可以单独发给我

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：
Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

--
--

doujiang24

Hello,

院生提供了一个失败用例，现在已经修复到 master 了 [1]

从你的描述的现象来看，很可能是是同一个 bug（但是从你的解决方式看来不太能理解）

欢迎你尝试一下这个修复

https://github.com/openresty/lua-resty-core/pull/35

在 2016年4月25日上午9:37，oysoft <oyc...@163.com>写道：

全局表使用set，直接使用semaphore instance为key，
push_semaphore_set={}
添加下面代码就能解决问题。
setmetatable(push_semaphore_set, { __mode = "k" })
不添加，就偶发上面crash。
在 2016年4月23日星期六 UTC+8上午12:18:07，doujiang写道：
Hello

在 2016年4月21日上午11:23，oysoft <oycw...@163.com>写道：
多谢提醒，
我把semaphore全局池改成弱引用表，问题就解决了，
猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

这个不应该的
你的全局表是什么结构呢，请求标识某种 string 为 key， semaphore instance 为 value ？
还有，你设置的 weak table 是 __mode = "kv" ?

semaphore 在被 gc 的时候，是有检查的，你可以检查错误日志来验证你的想法
https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_semaphore.c#L524

ps：是否有可复现的步骤描述呢，最好能去掉公司业务逻辑，这样方便公开讨论
或者，如果你不介意的话，可以单独发给我

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：
Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

--
--

oycwmail

多谢，前段时间去忙其他的了，我这几天观察后台，又出现这个crash了，我试试这个修复，多谢了

在 2016年5月5日星期四 UTC+8上午10:07:35，doujiang写道：

Hello,

院生提供了一个失败用例，现在已经修复到 master 了 [1]
从你的描述的现象来看，很可能是是同一个 bug（但是从你的解决方式看来不太能理解）

欢迎你尝试一下这个修复
https://github.com/openresty/lua-resty-core/pull/35
在 2016年4月25日上午9:37，oysoft <oycw...@163.com>写道：
全局表使用set，直接使用semaphore instance为key，
push_semaphore_set={}
添加下面代码就能解决问题。
setmetatable(push_semaphore_set, { __mode = "k" })
不添加，就偶发上面crash。
在 2016年4月23日星期六 UTC+8上午12:18:07，doujiang写道：
Hello

在 2016年4月21日上午11:23，oysoft <oycw...@163.com>写道：
多谢提醒，
我把semaphore全局池改成弱引用表，问题就解决了，
猜想是semaphore全局池保存的一些键(ngx.semaphore)已经无效，而协程还在wait引起的吧。

这个不应该的
你的全局表是什么结构呢，请求标识某种 string 为 key， semaphore instance 为 value ？
还有，你设置的 weak table 是 __mode = "kv" ?

semaphore 在被 gc 的时候，是有检查的，你可以检查错误日志来验证你的想法
https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_semaphore.c#L524

ps：是否有可复现的步骤描述呢，最好能去掉公司业务逻辑，这样方便公开讨论
或者，如果你不介意的话，可以单独发给我

在 2016年4月13日星期三 UTC+8下午9:54:17，doujiang写道：
Hello,

在 2016年4月8日上午10:59，oysoft <oycw...@163.com>写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。

你这个设计跟我之前搞的基本类似，但是我有高并发的压测，并没有碰到 core

你是直接使用 OpenResty 的发布版本，没有使用其他第三方 C 模块？

另外，这类问题调试比较麻烦，比较难定义，有可能 core 在这里，但是可能是错在更早的地方

所以，我的经验是：先提炼一个最小化样例
一来方便自己排查，二来也方便别人介入

低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--

--
--

agentzh

Hello!

2016-05-16 20:14 GMT-07:00 oysoft:
> 多谢，前段时间去忙其他的了，我这几天观察后台，又出现这个crash了，我试试这个修复，多谢了
>

值得一提的是，前面德江的修复已包含在最新的 OpenResty 1.9.15.1 RC1 版中了（见列表中今天的贴子）。

Regards,
-agentzh

oycwmail

hi，agentzh和doujiang：

我使用这个修复，没有解决问题，还是出现相同crash，还得继续分析一下。

在 2016年5月18日星期三 UTC+8下午12:10:33，agentzh写道：

Hello!

2016-05-16 20:14 GMT-07:00 oysoft:
> 多谢，前段时间去忙其他的了，我这几天观察后台，又出现这个crash了，我试试这个修复，多谢了
>

值得一提的是，前面德江的修复已包含在最新的 OpenResty 1.9.15.1 RC1 版中了（见列表中今天的贴子）。

Regards,
-agentzh

agentzh

Hello!

2016-05-17 21:28 GMT-07:00 oysoft:
> 我使用这个修复，没有解决问题，还是出现相同crash，还得继续分析一下。
>

你确认你使用的是 OpenResty 1.9.15.1 RC1 吗？另外，确保你重启了服务，而不是 HUP reload. 后者不会更新二进制程序。

Regards,
-agentzh

oycwmail

不是使用OpenResty 1.9.15.1 RC1，而是按https://github.com/openresty/lua-resty-core/pull/35 修复semaphore.lua这个文件。

在 2016年5月18日星期三 UTC+8下午12:39:22，agentzh写道：

Hello!

2016-05-17 21:28 GMT-07:00 oysoft:
> 我使用这个修复，没有解决问题，还是出现相同crash，还得继续分析一下。
>

你确认你使用的是 OpenResty 1.9.15.1 RC1 吗？另外，确保你重启了服务，而不是 HUP reload. 后者不会更新二进制程序。

Regards,
-agentzh

oycwmail

放弃使用ngx.semaphore，自己借用ngx.sleep只用lua不用扩展重写了semaphore模块，工作良好，但性能差了不少。

在 2016年5月18日星期三 UTC+8下午12:39:22，agentzh写道：

Hello!

2016-05-17 21:28 GMT-07:00 oysoft:
> 我使用这个修复，没有解决问题，还是出现相同crash，还得继续分析一下。
>

你确认你使用的是 OpenResty 1.9.15.1 RC1 吗？另外，确保你重启了服务，而不是 HUP reload. 后者不会更新二进制程序。

Regards,
-agentzh

agentzh

Hello!

2016-05-19 23:05 GMT-07:00 oysoft:
> 放弃使用ngx.semaphore，自己借用ngx.sleep只用lua不用扩展重写了semaphore模块，工作良好，但性能差了不少。
>

你能准备一个最小化的完整示例，以便我们的开发者可以在自己的环境复现 ngx.semaphore 的问题吗？多谢！

Regards,
-agentzh

soaercom

这个帖子我从头到尾的看完了，还是希望 @oysoft能提供最小测试用例，如果真的是有bug，应该提供一个可测试环境，然后让以后的人能够用到。

在 2016年4月8日星期五 UTC+8上午10:59:30，oysoft写道：

最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。
低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

doujiang24

Hello,

在 2016年8月4日下午3:23， <soa...@gmail.com>写道：

这个帖子我从头到尾的看完了，还是希望 @oysoft能提供最小测试用例

是的，能提供自然是大家有利，然而没有咱也强求不了

如果真的是有bug，应该提供一个可测试环境，然后让以后的人能够用到。

是否没 bug 很难说，不过我想大家还是可以放心使用

一来，我们已经在生产环境跑出单机百万级并发的稳定表现

二来，就算真碰到了 bug，只要大家配合，没有修复不了的 bug 哈，有春哥在，放心用，哈哈

在 2016年4月8日星期五 UTC+8上午10:59:30，oysoft写道：
最近在用openresty 1.9.7.3做push，之前的思路是
一个连接开两个协程，一个协程接受客户端请求，一个协程从redis获得订阅的数据，处理后返回给客户端，工作正常，就是负载有点高。
现在我尝试使用ngx.semaphore来优化push：
用ngx.timer.at开一个后台协程专门负责连接redis获得订阅的数据，处理后保存在全局变量中，遍历semaphore全局池，对每一个semaphore执行post操作。
请求到达后，对应的协程创建semaphore，并把semaphore放入一个全局池子中，并wait，有事件触发后从全局变量获取数据。
低并发下情况没有问题，高并发下nginx偶发crash，拿到core，分析：
Core was generated by `nginx: worker process '.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
31 ngx_delete_posted_event(ev);
(gdb) bt
#0 0x00000000004433a8 in ngx_event_process_posted (cycle=0x12ef980, posted=0x7b03b0 <ngx_posted_events>)
at src/event/ngx_event_posted.c:31
#1 0x00000000004414f1 in ngx_process_events_and_timers (cycle=0x12ef980) at src/event/ngx_event.c:259
#2 0x000000000044c127 in ngx_worker_process_cycle (cycle=0x12ef980, data="" at src/os/unix/ngx_process_cycle.c:753
#3 0x00000000004490ae in ngx_spawn_process (cycle=0x12ef980, proc=0x44c068 <ngx_worker_process_cycle>, data="">
name=0x55e0b0 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198
#4 0x000000000044b380 in ngx_start_worker_processes (cycle=0x12ef980, n=8, type=-4)
at src/os/unix/ngx_process_cycle.c:358
#5 0x000000000044af50 in ngx_master_process_cycle (cycle=0x12ef980) at src/os/unix/ngx_process_cycle.c:243
#6 0x000000000041acd9 in main (argc=1, argv=0x7fff5c0f7b18) at src/core/nginx.c:359
(gdb) l
26 ev = ngx_queue_data(q, ngx_event_t, queue);
27
28 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
29 "posted event %p", ev);
30
31 ngx_delete_posted_event(ev);
32
33 ev->handler(ev);
34 }
35 }
(gdb) p *ev
$5 = {data = "" write = 0, accept = 0, instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0,
complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof = 0,
posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0,
handler = 0x520423 <ngx_http_lua_semaphore_handler>, index = 0, log = 0x12ef998, timer = {key = 0, left = 0x0,
right = 0x0, parent = 0x0, color = 0 '\000', data = 0 '\000'}, queue = {prev = 0x7b03b0 <ngx_posted_events>,
next = 0x0}}
因为对nginx内部代码了解不多，没有什么解决思路，还望达人指导。

--