问大家一个关于调试的问题（GDB）

382482175 · 2016-09-28T12:15:47+00:00

=== TEST 4: test--- config location = /test { content_by_lua ' local args = ngx.req.get_uri_args() for key, val in pairs(args) do if type(val) ==...

问大家一个关于调试的问题（GDB）

382482175

在nginx中，发现了某个某块把超时时间为0的timer加入了timer树，而这个timer又会重复加入timer为0的timer，这样导致陷入了

ngx_event_expire_timers的死循环，一直再处理这个函数，导致cpu飙高。

问题就是这个时间是被篡改为了0，而正常的情况下，应该是被初始化为1000ms的，但是不知道是在哪里被改的，现在进入了循环，也跳不出来，不知道有啥办法知道在哪里被改动了。

另外这个问题是不可复现的，昨天出现了一次，reload后正常了，今天又出现了，所以不能reload。

moonbingbing

https://github.com/openresty/stapxx#lj-lua-bt 这个工具可以获取当前的 Lua 调用栈，可以精确到代码行数。

你试试，能否满足你的要求。当然，这个工具不用你 reload NGINX。

在 2016年9月28日下午12:15，wwaz wwaz <3824...@qq.com>写道：

在nginx中，发现了某个某块把超时时间为0的timer加入了timer树，而这个timer又会重复加入timer为0的timer，这样导致陷入了
ngx_event_expire_timers的死循环，一直再处理这个函数，导致cpu飙高。

问题就是这个时间是被篡改为了0，而正常的情况下，应该是被初始化为1000ms的，但是不知道是在哪里被改的，现在进入了循环，也跳不出来，不知道有啥办法知道在哪里被改动了。

另外这个问题是不可复现的，昨天出现了一次，reload后正常了，今天又出现了，所以不能reload。

--

382482175

谢谢回复。

这个工具貌似是调试lua代码的吧

我的这个问题主要是不能reload，reload后就消失了，不重现，现在这个飙高的worker陷入了死循环，其实是check_upstream模块的interval时间被篡改为了0.。

在 2016年9月28日星期三 UTC+8下午2:52:15，WenMing写道：

https://github.com/openresty/stapxx#lj-lua-bt 这个工具可以获取当前的 Lua 调用栈，可以精确到代码行数。
你试试，能否满足你的要求。当然，这个工具不用你 reload NGINX。

在 2016年9月28日下午12:15，wwaz wwaz <3824...@qq.com>写道：
在nginx中，发现了某个某块把超时时间为0的timer加入了timer树，而这个timer又会重复加入timer为0的timer，这样导致陷入了
ngx_event_expire_timers的死循环，一直再处理这个函数，导致cpu飙高。

问题就是这个时间是被篡改为了0，而正常的情况下，应该是被初始化为1000ms的，但是不知道是在哪里被改的，现在进入了循环，也跳不出来，不知道有啥办法知道在哪里被改动了。

另外这个问题是不可复现的，昨天出现了一次，reload后正常了，今天又出现了，所以不能reload。

--

moonbingbing

你的不是 lua 代码？是 C 模块？

https://github.com/openresty/stapxx 和 https://github.com/openresty/nginx-systemtap-toolkit 里面的动态跟踪工具都不需要 reload NGINX的。

在 2016年9月28日下午4:43，wwaz wwaz <3824...@qq.com>写道：

谢谢回复。
这个工具貌似是调试lua代码的吧

我的这个问题主要是不能reload，reload后就消失了，不重现，现在这个飙高的worker陷入了死循环，其实是check_upstream模块的interval时间被篡改为了0.。

在 2016年9月28日星期三 UTC+8下午2:52:15，WenMing写道：
https://github.com/openresty/stapxx#lj-lua-bt 这个工具可以获取当前的 Lua 调用栈，可以精确到代码行数。
你试试，能否满足你的要求。当然，这个工具不用你 reload NGINX。

在 2016年9月28日下午12:15，wwaz wwaz <3824...@qq.com>写道：
在nginx中，发现了某个某块把超时时间为0的timer加入了timer树，而这个timer又会重复加入timer为0的timer，这样导致陷入了
ngx_event_expire_timers的死循环，一直再处理这个函数，导致cpu飙高。

问题就是这个时间是被篡改为了0，而正常的情况下，应该是被初始化为1000ms的，但是不知道是在哪里被改的，现在进入了循环，也跳不出来，不知道有啥办法知道在哪里被改动了。

另外这个问题是不可复现的，昨天出现了一次，reload后正常了，今天又出现了，所以不能reload。

--

--