共享内存出错

daxiong1515 · 2018-03-06T11:28:39+00:00

Hello! 测试的时候观察下cpu, 硬盘io, 网卡io有没异&#x5E38...

共享内存出错

daxiong1515

hi, All

最近遇到一个奇怪的报错

日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key" was locked by 20038

出现这个错误的问题操作是函数是： Session:set("123456798", "abcde", 700)

只要操作这个函数就会出现以上日志，然后nginx 的子进程就会退出，接着 master 会重新起一个新的子进程。

以上结果无限循环。

使用strace 追踪，最后是收到 SIGSEGV 信号。也就是出现了 Segment fault 错误，大概猜想是访问到了一个空指针了吧。

nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。

目前只出现一次问题。

使用版本： openresty 1.13.6.1

zchao1995

Hello!

> 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key" was locked by 20038

这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。

> nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。

reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，

猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。

题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。

daxiong1515

我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，

如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864", 7200) 这就是我的设置命令，每条都是一样的格式。

我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。

在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：

Hello!

> 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key" was locked by 20038

这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。

> nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。

reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。

题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。

--

hongliang5316

Hello!

请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?

另外你的OpenResty版本是多少? 如何安装的呢?

最好能根据你的代码提供一个最小化的复现样例以便我们分析.

在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：

我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864", 7200) 这就是我的设置命令，每条都是一样的格式。

我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。

在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
Hello!

> 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key" was locked by 20038

这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。

> nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。

reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。

题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。

--

daxiong1515

hello，
openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境出现问题。

现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。

在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：

Hello!
请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?
另外你的OpenResty版本是多少? 如何安装的呢?
最好能根据你的代码提供一个最小化的复现样例以便我们分析.

在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864", 7200) 这就是我的设置命令，每条都是一样的格式。

我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。

在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
Hello!

> 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key" was locked by 20038

这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。

> nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。

reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。

题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。

--

spacewanderlzx

x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
里面有不少内存分配上的 hack，说不定就是这个问题。
当然没看到 core dump，这个只是猜测。

在 2018年3月7日 下午4:47，大雄 <daxio...@gmail.com> 写道：
> hello，
>    openresty 版本是 1.13.6.1 ，  openresty 是在嵌入式环境运行，在x86环境 没见过， 目前在 mips 环境 出现
> 问题。
>    现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现  我尽快来反馈。
>
>
> 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>>
>> Hello!
>>    请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?
>>    另外你的OpenResty版本是多少? 如何安装的呢?
>>    最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>>
>> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>>>
>>> 我写入的key 和 val 都是明文，是做 网站的session key 保存，格式也是很固定的，
>>>  如：   Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864",
>>> 7200)  这就是我的设置命令，每条都是一样的格式。
>>>
>>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>>>
>>>
>>> 在 2018年3月6日 上午11:40，tokers <zcha...@gmail.com>写道：
>>>>
>>>> Hello!
>>>>
>>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key"
>>>> > was locked by 20038
>>>>
>>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>>>>
>>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>>>>
>>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>>>>
>>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>>>>
>>>> --
>>>> --
>

daxiong1515

好的，到时候有复现时，我整一下 code dump 。

另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。

--- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800

+++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800

@@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_

#if !(NGX_HAVE_ATOMIC_OPS)

-#define NGX_HAVE_ATOMIC_OPS 0

+#define NGX_HAVE_ATOMIC_OPS 1

typedef int32_t ngx_atomic_int_t;

typedef uint32_t ngx_atomic_uint_t;

在 2018年3月7日下午4:57，Zexuan Luo <spacew...@gmail.com>写道：

x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
里面有不少内存分配上的 hack，说不定就是这个问题。
当然没看到 core dump，这个只是猜测。

在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
> hello，
> openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境出现
> 问题。
> 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>
>
> 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>>
>> Hello!
>> 请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?
>> 另外你的OpenResty版本是多少? 如何安装的呢?
>> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>>
>> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>>>
>>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864",
>>> 7200) 这就是我的设置命令，每条都是一样的格式。
>>>
>>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>>>
>>>
>>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>>>>
>>>> Hello!
>>>>
>>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key"
>>>> > was locked by 20038
>>>>
>>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>>>>
>>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>>>>
>>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>>>>
>>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>>>>
>>>> --
>>>>
>>>
> --
>
--

spacewanderlzx

……明明不支持 ATOMIC_OPS 的，你这么改之后会让 Nginx 误认为支持 ATOMIC_OPS，怎么可能会是对的呢

在 2018年3月7日 下午5:12，大雄 <daxio...@gmail.com> 写道：
> 好的， 到时候有复现时，我整一下 code dump 。
> 另外我想起一件事， 当时在mips环境编译不过去，我看一下错误， 改了一下让他编译过去，我觉得我这个改动是对的。
>
> --- a/src/os/unix/ngx_atomic.h  2017-12-07 17:03:35.196488805 +0800
> +++ b/src/os/unix/ngx_atomic.h  2017-12-07 17:03:28.687224371 +0800
> @@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t  ngx_
>
>  #if !(NGX_HAVE_ATOMIC_OPS)
>
> -#define NGX_HAVE_ATOMIC_OPS  0
> +#define NGX_HAVE_ATOMIC_OPS  1
>
>  typedef int32_t                     ngx_atomic_int_t;
>  typedef uint32_t                    ngx_atomic_uint_t;
>
> 在 2018年3月7日 下午4:57，Zexuan Luo <spacew...@gmail.com>写道：
>>
>> x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
>> x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
>> 里面有不少内存分配上的 hack，说不定就是这个问题。
>> 当然没看到 core dump，这个只是猜测。
>>
>> 在 2018年3月7日 下午4:47，大雄 <daxio...@gmail.com> 写道：
>> > hello，
>> >    openresty 版本是 1.13.6.1 ，  openresty 是在嵌入式环境运行，在x86环境 没见过， 目前在 mips 环境
>> > 出现
>> > 问题。
>> >    现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现  我尽快来反馈。
>> >
>> >
>> > 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>> >>
>> >> Hello!
>> >>    请问你除了用`ngx.shared` API操作`sess_key` 的shm
>> >> zone之外还有没有别的nginx第三方module操作过呢?
>> >>    另外你的OpenResty版本是多少? 如何安装的呢?
>> >>    最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>> >>
>> >> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>> >>>
>> >>> 我写入的key 和 val 都是明文，是做 网站的session key 保存，格式也是很固定的，
>> >>>  如：   Session:set("b026324c6904b2a9cb4b88d6d61c81d1",
>> >>> "admin&1520307864",
>> >>> 7200)  这就是我的设置命令，每条都是一样的格式。
>> >>>
>> >>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>> >>>
>> >>>
>> >>> 在 2018年3月6日 上午11:40，tokers <zcha...@gmail.com>写道：
>> >>>>
>> >>>> Hello!
>> >>>>
>> >>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone
>> >>>> > "sess_key"
>> >>>> > was locked by 20038
>> >>>>
>> >>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>> >>>>
>> >>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>> >>>>
>> >>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>> >>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>> >>>>
>> >>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>> >>>>
>> >>>> --
>> >>>> --
>> > --
>> --
>

daxiong1515

从它的宏定义看，前面有一堆的检查 ATOMIC 是否支持，如果不支持的话则会重新封装函数，

从逻辑上看，也就是说如果前面不支持 ATOMIC 会重新定义，并且把 NGX_HAVE_ATOMIC_OPS = 1 ，如果不是这样的话

那么它的这个逻辑就是多余的了

#if !(NGX_HAVE_ATOMIC_OPS)

#define NGX_HAVE_ATOMIC_OPS 0

....

#endif

所以，按我的理解应该是 NGX_HAVE_ATOMIC_OPS = 0 的话，重新定义 ngx_atomic_cmp_set 和 ngx_atomic_fetch_add ，并且把 NGX_HAVE_ATOMIC_OPS = 1 。

在 2018年3月7日下午5:28，Zexuan Luo <spacew...@gmail.com>写道：

……明明不支持 ATOMIC_OPS 的，你这么改之后会让 Nginx 误认为支持 ATOMIC_OPS，怎么可能会是对的呢

在 2018年3月7日下午5:12，大雄 <daxio...@gmail.com> 写道：
> 好的，到时候有复现时，我整一下 code dump 。
> 另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。
>
> --- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800
> +++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800
> @@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_
>
> #if !(NGX_HAVE_ATOMIC_OPS)
>
> -#define NGX_HAVE_ATOMIC_OPS 0
> +#define NGX_HAVE_ATOMIC_OPS 1
>
> typedef int32_t ngx_atomic_int_t;
> typedef uint32_t ngx_atomic_uint_t;
>
> 在 2018年3月7日下午4:57，Zexuan Luo <spacew...@gmail.com>写道：
>>
>> x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
>> x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
>> 里面有不少内存分配上的 hack，说不定就是这个问题。
>> 当然没看到 core dump，这个只是猜测。
>>
>> 在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
>> > hello，
>> > openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境
>> > 出现
>> > 问题。
>> > 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>> >
>> >
>> > 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>> >>
>> >> Hello!
>> >> 请问你除了用`ngx.shared` API操作`sess_key` 的shm
>> >> zone之外还有没有别的nginx第三方module操作过呢?
>> >> 另外你的OpenResty版本是多少? 如何安装的呢?
>> >> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>> >>
>> >> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>> >>>
>> >>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>> >>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1",
>> >>> "admin&1520307864",
>> >>> 7200) 这就是我的设置命令，每条都是一样的格式。
>> >>>
>> >>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>> >>>
>> >>>
>> >>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>> >>>>
>> >>>> Hello!
>> >>>>
>> >>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone
>> >>>> > "sess_key"
>> >>>> > was locked by 20038
>> >>>>
>> >>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>> >>>>
>> >>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>> >>>>
>> >>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>> >>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>> >>>>
>> >>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>> >>>>
>> >>>> --
>> >>>>
>> >>>
>> > --
>> >
>> --
>>
>
> --
>
--

daxiong1515

在 2018年3月7日下午5:34，大雄 <daxio...@gmail.com>写道：

从它的宏定义看，前面有一堆的检查 ATOMIC 是否支持，如果不支持的话则会重新封装函数，
从逻辑上看，也就是说如果前面不支持 ATOMIC 会重新定义，并且把 NGX_HAVE_ATOMIC_OPS = 1 ，如果不是这样的话
那么它的这个逻辑就是多余的了
#if !(NGX_HAVE_ATOMIC_OPS)

#define NGX_HAVE_ATOMIC_OPS 0
....
....
#endif

所以，按我的理解应该是 NGX_HAVE_ATOMIC_OPS = 0 的话，重新定义 ngx_atomic_cmp_set 和 ngx_atomic_fetch_add ，并且把 NGX_HAVE_ATOMIC_OPS = 1 。

在 2018年3月7日下午5:28，Zexuan Luo <spacew...@gmail.com>写道：
……明明不支持 ATOMIC_OPS 的，你这么改之后会让 Nginx 误认为支持 ATOMIC_OPS，怎么可能会是对的呢

在 2018年3月7日下午5:12，大雄 <daxio...@gmail.com> 写道：
> 好的，到时候有复现时，我整一下 code dump 。
> 另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。
>
> --- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800
> +++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800
> @@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_
>
> #if !(NGX_HAVE_ATOMIC_OPS)
>
> -#define NGX_HAVE_ATOMIC_OPS 0
> +#define NGX_HAVE_ATOMIC_OPS 1
>
> typedef int32_t ngx_atomic_int_t;
> typedef uint32_t ngx_atomic_uint_t;
>
> 在 2018年3月7日下午4:57，Zexuan Luo <spacew...@gmail.com>写道：
>>
>> x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
>> x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
>> 里面有不少内存分配上的 hack，说不定就是这个问题。
>> 当然没看到 core dump，这个只是猜测。
>>
>> 在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
>> > hello，
>> > openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境
>> > 出现
>> > 问题。
>> > 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>> >
>> >
>> > 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>> >>
>> >> Hello!
>> >> 请问你除了用`ngx.shared` API操作`sess_key` 的shm
>> >> zone之外还有没有别的nginx第三方module操作过呢?
>> >> 另外你的OpenResty版本是多少? 如何安装的呢?
>> >> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>> >>
>> >> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>> >>>
>> >>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>> >>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1",
>> >>> "admin&1520307864",
>> >>> 7200) 这就是我的设置命令，每条都是一样的格式。
>> >>>
>> >>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>> >>>
>> >>>
>> >>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>> >>>>
>> >>>> Hello!
>> >>>>
>> >>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone
>> >>>> > "sess_key"
>> >>>> > was locked by 20038
>> >>>>
>> >>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>> >>>>
>> >>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>> >>>>
>> >>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>> >>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>> >>>>
>> >>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>> >>>>
>> >>>> --
>> >>>>
>> >>>
>> > --
>> >
>> --
>>
>
> --
>
--

spacewanderlzx

那两个重新定义的 ngx_atomic_* 函数的实现并不是原子的，恐怕只是为了能够在不需要准确的原子操作的地方能够编译通过才定义的。

在 2018年3月7日下午5:35，大雄 <daxio...@gmail.com>写道：

在 2018年3月7日下午5:34，大雄 <daxio...@gmail.com>写道：
从它的宏定义看，前面有一堆的检查 ATOMIC 是否支持，如果不支持的话则会重新封装函数，
从逻辑上看，也就是说如果前面不支持 ATOMIC 会重新定义，并且把 NGX_HAVE_ATOMIC_OPS = 1 ，如果不是这样的话
那么它的这个逻辑就是多余的了
#if !(NGX_HAVE_ATOMIC_OPS)

#define NGX_HAVE_ATOMIC_OPS 0
....
....
#endif

所以，按我的理解应该是 NGX_HAVE_ATOMIC_OPS = 0 的话，重新定义 ngx_atomic_cmp_set 和 ngx_atomic_fetch_add ，并且把 NGX_HAVE_ATOMIC_OPS = 1 。

在 2018年3月7日下午5:28，Zexuan Luo <spacew...@gmail.com>写道：
……明明不支持 ATOMIC_OPS 的，你这么改之后会让 Nginx 误认为支持 ATOMIC_OPS，怎么可能会是对的呢

在 2018年3月7日下午5:12，大雄 <daxio...@gmail.com> 写道：
> 好的，到时候有复现时，我整一下 code dump 。
> 另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。
>
> --- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800
> +++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800
> @@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_
>
> #if !(NGX_HAVE_ATOMIC_OPS)
>
> -#define NGX_HAVE_ATOMIC_OPS 0
> +#define NGX_HAVE_ATOMIC_OPS 1
>
> typedef int32_t ngx_atomic_int_t;
> typedef uint32_t ngx_atomic_uint_t;
>
> 在 2018年3月7日下午4:57，Zexuan Luo <spacew...@gmail.com>写道：
>>
>> x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
>> x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
>> 里面有不少内存分配上的 hack，说不定就是这个问题。
>> 当然没看到 core dump，这个只是猜测。
>>
>> 在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
>> > hello，
>> > openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境
>> > 出现
>> > 问题。
>> > 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>> >
>> >
>> > 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>> >>
>> >> Hello!
>> >> 请问你除了用`ngx.shared` API操作`sess_key` 的shm
>> >> zone之外还有没有别的nginx第三方module操作过呢?
>> >> 另外你的OpenResty版本是多少? 如何安装的呢?
>> >> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>> >>
>> >> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>> >>>
>> >>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>> >>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1",
>> >>> "admin&1520307864",
>> >>> 7200) 这就是我的设置命令，每条都是一样的格式。
>> >>>
>> >>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>> >>>
>> >>>
>> >>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>> >>>>
>> >>>> Hello!
>> >>>>
>> >>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone
>> >>>> > "sess_key"
>> >>>> > was locked by 20038
>> >>>>
>> >>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>> >>>>
>> >>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>> >>>>
>> >>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>> >>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>> >>>>
>> >>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>> >>>>
>> >>>> --
>> >>>>
>> >>>
>> > --
>> >
>> --
>>
>
> --
>
--

--

zchao1995

我比较好奇你这里的编译错误是什么？方便贴一下图吗？

不支持原子变量的时候，一些需要用到互斥锁的情况下，它会用文件锁来替代。

On Wednesday, March 7, 2018 at 5:12:16 PM UTC+8, 大雄 wrote:

好的，到时候有复现时，我整一下 code dump 。
另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。

--- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800
+++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800
@@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_

#if !(NGX_HAVE_ATOMIC_OPS)

-#define NGX_HAVE_ATOMIC_OPS 0
+#define NGX_HAVE_ATOMIC_OPS 1

typedef int32_t ngx_atomic_int_t;
typedef uint32_t ngx_atomic_uint_t;

在 2018年3月7日下午4:57，Zexuan Luo <spacewa...@gmail.com>写道：
x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
里面有不少内存分配上的 hack，说不定就是这个问题。
当然没看到 core dump，这个只是猜测。

在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
> hello，
> openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境出现
> 问题。
> 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>
>
> 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>>
>> Hello!
>> 请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?
>> 另外你的OpenResty版本是多少? 如何安装的呢?
>> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>>
>> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>>>
>>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864",
>>> 7200) 这就是我的设置命令，每条都是一样的格式。
>>>
>>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>>>
>>>
>>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>>>>
>>>> Hello!
>>>>
>>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key"
>>>> > was locked by 20038
>>>>
>>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>>>>
>>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>>>>
>>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>>>>
>>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>>>>
>>>> --
>>>>
>>>
> --
>
--

daxiong1515

hello,

tokers

我发邮件给你了

在 2018年3月7日下午5:47，tokers <zcha...@gmail.com>写道：

我比较好奇你这里的编译错误是什么？方便贴一下图吗？
不支持原子变量的时候，一些需要用到互斥锁的情况下，它会用文件锁来替代。

On Wednesday, March 7, 2018 at 5:12:16 PM UTC+8, 大雄 wrote:
好的，到时候有复现时，我整一下 code dump 。
另外我想起一件事，当时在mips环境编译不过去，我看一下错误，改了一下让他编译过去，我觉得我这个改动是对的。

--- a/src/os/unix/ngx_atomic.h 2017-12-07 17:03:35.196488805 +0800
+++ b/src/os/unix/ngx_atomic.h 2017-12-07 17:03:28.687224371 +0800
@@ -266,7 +266,7 @@ typedef volatile ngx_atomic_uint_t ngx_

#if !(NGX_HAVE_ATOMIC_OPS)

-#define NGX_HAVE_ATOMIC_OPS 0
+#define NGX_HAVE_ATOMIC_OPS 1

typedef int32_t ngx_atomic_int_t;
typedef uint32_t ngx_atomic_uint_t;

在 2018年3月7日下午4:57，Zexuan Luo <spacewa...@gmail.com>写道：
x86 没问题，MIPS 下才会出现，难道是 memory alignment 的问题？
x86 和现代 arm 里面，即使访问的内存地址没有对齐，也不会有问题。但是其他硬件架构就未必了。考虑到 Nginx/OpenResty
里面有不少内存分配上的 hack，说不定就是这个问题。
当然没看到 core dump，这个只是猜测。

在 2018年3月7日下午4:47，大雄 <daxio...@gmail.com> 写道：
> hello，
> openresty 版本是 1.13.6.1 ， openresty 是在嵌入式环境运行，在x86环境没见过，目前在 mips 环境出现
> 问题。
> 现在我也没有好的办法让他复现，我再继续观察，如果能有好的复现我尽快来反馈。
>
>
> 在 2018年3月6日星期二 UTC+8下午2:18:09，hongli...@gmail.com写道：
>>
>> Hello!
>> 请问你除了用`ngx.shared` API操作`sess_key` 的shm zone之外还有没有别的nginx第三方module操作过呢?
>> 另外你的OpenResty版本是多少? 如何安装的呢?
>> 最好能根据你的代码提供一个最小化的复现样例以便我们分析.
>>
>> 在 2018年3月6日星期二 UTC+8上午11:52:45，大雄写道：
>>>
>>> 我写入的key 和 val 都是明文，是做网站的session key 保存，格式也是很固定的，
>>> 如： Session:set("b026324c6904b2a9cb4b88d6d61c81d1", "admin&1520307864",
>>> 7200) 这就是我的设置命令，每条都是一样的格式。
>>>
>>> 我的环境在嵌入式环境，没有coredump，我尝试一下看能否使用coredump。
>>>
>>>
>>> 在 2018年3月6日上午11:40，tokers <zcha...@gmail.com>写道：
>>>>
>>>> Hello!
>>>>
>>>> > 日志： 2018/03/06 10:54:19 [alert] 841#0: shared memory zone "sess_key"
>>>> > was locked by 20038
>>>>
>>>> 这说明 20038 这个进程在锁住这块共享内存后，还没来得及释放，就因为一些问题异常退出了。
>>>>
>>>> > nginx -s reload 无法解决问题，如果把进程stop 再start 一次，就不能重现问题。
>>>>
>>>> reload 的时候，如果不修改共享内存大小，那么这块共享内存还是会被复用的，
>>>> 猜测可能这块共享内存是否被写入了脏数据导致比如 slab 池的一些信息被损坏了。
>>>>
>>>> 题主有对应的 coredump 文件吗，最好可以导入到 gdb，打印一下堆栈，以便分析观察。
>>>>
>>>> --
>>>>
>>>
> --
>
--

--

zchao1995

Hello!

从你的报错来看，是因为实现读写锁，依赖于这个原子变量。

我看了下读写锁的话，只有 upstream 模块的 zone 特性在用的，对应宏是 NGX_HTTP_UPSTREAM_ZONE，这个宏无条件设置为 1。

如果你的配置里没有用到 upstream 模块的 zone 的话，可以考虑把 NGX_HTTP_UPSTREAM_ZONE 关掉。

另外方便贴下你发我的报错截图吗？方便大家一起分析。

daxiong1515

在 2018年3月7日下午6:02，tokers <zcha...@gmail.com>写道：

Hello!

从你的报错来看，是因为实现读写锁，依赖于这个原子变量。
我看了下读写锁的话，只有 upstream 模块的 zone 特性在用的，对应宏是 NGX_HTTP_UPSTREAM_ZONE，这个宏无条件设置为 1。
如果你的配置里没有用到 upstream 模块的 zone 的话，可以考虑把 NGX_HTTP_UPSTREAM_ZONE 关掉。

另外方便贴下你发我的报错截图吗？方便大家一起分析。

--

daxiong1515

我编译时加参数 --without-http_upstream_zone_module 来关闭模块可以吗？

在 2018年3月7日下午6:05，大雄 <daxio...@gmail.com>写道：

在 2018年3月7日下午6:02，tokers <zcha...@gmail.com>写道：
Hello!

从你的报错来看，是因为实现读写锁，依赖于这个原子变量。
我看了下读写锁的话，只有 upstream 模块的 zone 特性在用的，对应宏是 NGX_HTTP_UPSTREAM_ZONE，这个宏无条件设置为 1。
如果你的配置里没有用到 upstream 模块的 zone 的话，可以考虑把 NGX_HTTP_UPSTREAM_ZONE 关掉。

另外方便贴下你发我的报错截图吗？方便大家一起分析。

--

daxiong1515

我增加 --without-http_upstream_zone_module 参数，编译不会报错了。

按这样来看，因为我没有使用 upstream 模块，所以我遇到的共享内存问题，跟我打补丁其实是无关的是吗？

在 2018年3月7日下午6:11，大雄 <daxio...@gmail.com>写道：

我编译时加参数 --without-http_upstream_zone_module 来关闭模块可以吗？

在 2018年3月7日下午6:05，大雄 <daxio...@gmail.com>写道：

在 2018年3月7日下午6:02，tokers <zcha...@gmail.com>写道：
Hello!

从你的报错来看，是因为实现读写锁，依赖于这个原子变量。
我看了下读写锁的话，只有 upstream 模块的 zone 特性在用的，对应宏是 NGX_HTTP_UPSTREAM_ZONE，这个宏无条件设置为 1。
如果你的配置里没有用到 upstream 模块的 zone 的话，可以考虑把 NGX_HTTP_UPSTREAM_ZONE 关掉。

另外方便贴下你发我的报错截图吗？方便大家一起分析。

--

daxiong1515

hi， tokers

今天又重现问题，我已经把 coredump 导出来发邮件给你了。

在 2018年3月7日星期三 UTC+8下午6:02:40，tokers写道：

Hello!

从你的报错来看，是因为实现读写锁，依赖于这个原子变量。
我看了下读写锁的话，只有 upstream 模块的 zone 特性在用的，对应宏是 NGX_HTTP_UPSTREAM_ZONE，这个宏无条件设置为 1。
如果你的配置里没有用到 upstream 模块的 zone 的话，可以考虑把 NGX_HTTP_UPSTREAM_ZONE 关掉。

另外方便贴下你发我的报错截图吗？方便大家一起分析。

zchao1995

Hello!

刚看了下，红黑树节点居然出现了空值，正常情况下，如果左儿子/右儿子空的话，都会赋值成 sentinel 节点。目前没有看出端倪。:(

daxiong1515

hello, tokers

出现空指针，那会不会有某些地方把值设为 NULL ，

我觉得应该需要针对 NULL值专门处理一下逻辑吧。

有没有临时的解决办法建议让我打个patch 进去，比如得到NULL 的时候我让 ngx_rbtree_delete 的函数直接 return 是否可以？

在 2018年3月14日下午7:17，tokers <zcha...@gmail.com>写道：

Hello!

刚看了下，红黑树节点居然出现了空值，正常情况下，如果左儿子/右儿子空的话，都会赋值成 sentinel 节点。目前没有看出端倪。:(

--