Updated ndk_md5_hash() to work with updated NDK #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
merge done. thanks! |
Closed
Closed
Closed
ghost
mentioned this pull request
thibaultcha
added a commit
to thibaultcha/lua-nginx-module
that referenced
this pull request
Feb 15, 2019
This issue appeared in our EC2 test cluster, which compiles Nginx with
`-DNGX_LUA_USE_ASSERT` and `-DNGX_LUA_ABORT_AT_PANIC`.
The lua-resty-redis test:
=== TEST 1: github issue openresty#108: ngx.locaiton.capture + redis.set_keepalive
in t/bugs.t [1] would produce core dumps in the check leak testing mode.
The backtrace for these core dumps was:
#0 0x00007fd417bee277 in raise () from /lib64/libc.so.6
openresty#1 0x00007fd417bef968 in abort () from /lib64/libc.so.6
openresty#2 0x00007fd417be7096 in __assert_fail_base () from /lib64/libc.so.6
openresty#3 0x00007fd417be7142 in __assert_fail () from /lib64/libc.so.6
openresty#4 0x000000000050d227 in ngx_http_lua_socket_tcp_resume_conn_op (spool=c/ngx_http_lua_socket_tcp.c:3963
openresty#5 0x000000000050e51a in ngx_http_lua_socket_tcp_finalize (r=r@entry=0x5628) at ../../src/ngx_http_lua_socket_tcp.c:4195
openresty#6 0x000000000050e570 in ngx_http_lua_socket_tcp_cleanup (data=0x7fd419p_lua_socket_tcp.c:3755
openresty#7 0x0000000000463aa5 in ngx_http_free_request (r=r@entry=0xbfaec0, rc=http_request.c:3508
...
Which was caused by the following assertion in ngx_http_lua_socket_tcp.c
with `NGX_DEBUG`:
#if (NGX_DEBUG)
ngx_http_lua_assert(spool->connections >= 0);
#else
Thanks to Mozilla's rr, a recorded session showed that
`spool->connections` was `-1`.
Unfortunately, reproducing this case does not seem possible, since the
failure is due to the request cleanup (`ngx_http_free_request`). Here is
an explanation:
-- thread 1
local sock = ngx.socket.tcp()
sock:connect()
sock:setkeepalive() -- pool created, connections: 1
-- thread 2
local sock = ngx.socket.tcp()
sock:connect() -- from pool, connections: 1
-- thread 1
-- sock from thread 1 idle timeout, closes, and calls
-- ngx_http_lua_socket_tcp_finalize, connections: 0
-- thread 2
sock:setkeepalive() -- connections: -1
-- ngx_http_lua_socket_tcp_resume_conn_op gets called, assertion fails
In order to avoid this race condition, we must determine whether the
socket pool exists or not, not from the
`ngx_http_lua_socket_tcp_upstream` struct, but from the Lua Registry.
This way, when thread 2's socket enters the keepalive state, it will
respect the previous call to `ngx_http_lua_socket_free_pool` (which
unset the pool from the registry).
[1]: https://github.com/openresty/lua-resty-redis/blob/master/t/bugs.t
thibaultcha
added a commit
to thibaultcha/lua-nginx-module
that referenced
this pull request
Feb 16, 2019
This issue appeared in our EC2 test cluster, which compiles Nginx with
`-DNGX_LUA_USE_ASSERT` and `-DNGX_LUA_ABORT_AT_PANIC`.
The lua-resty-redis test:
=== TEST 1: github issue openresty#108: ngx.locaiton.capture + redis.set_keepalive
in t/bugs.t [1] would produce core dumps in the check leak testing mode.
The backtrace for these core dumps was:
#0 0x00007fd417bee277 in raise () from /lib64/libc.so.6
openresty#1 0x00007fd417bef968 in abort () from /lib64/libc.so.6
openresty#2 0x00007fd417be7096 in __assert_fail_base () from /lib64/libc.so.6
openresty#3 0x00007fd417be7142 in __assert_fail () from /lib64/libc.so.6
openresty#4 0x000000000050d227 in ngx_http_lua_socket_tcp_resume_conn_op (spool=c/ngx_http_lua_socket_tcp.c:3963
openresty#5 0x000000000050e51a in ngx_http_lua_socket_tcp_finalize (r=r@entry=0x5628) at ../../src/ngx_http_lua_socket_tcp.c:4195
openresty#6 0x000000000050e570 in ngx_http_lua_socket_tcp_cleanup (data=0x7fd419p_lua_socket_tcp.c:3755
openresty#7 0x0000000000463aa5 in ngx_http_free_request (r=r@entry=0xbfaec0, rc=http_request.c:3508
...
Which was caused by the following assertion in ngx_http_lua_socket_tcp.c
with `NGX_DEBUG`:
#if (NGX_DEBUG)
ngx_http_lua_assert(spool->connections >= 0);
#else
Thanks to Mozilla's rr, a recorded session showed that
`spool->connections` was `-1`.
Here is a reproducible test case:
local sock1 = ngx.socket.tcp()
local sock2 = ngx.socket.tcp()
sock1:connect()
sock2:connect()
sock1:setkeepalive() -- pool created, connections: 1
sock2:setkeepalive() -- connections: 1
sock1:connect() -- connections: 1
sock2:connect() -- connections: 1
sock1:close() -- connections: 0
sock2:close() -- connections: -1
-- ngx_http_lua_socket_tcp_resume_conn_op gets called, assertion fails
In order to avoid this race condition, we must determine whether the
socket pool exists or not, not from the
`ngx_http_lua_socket_tcp_upstream` struct, but from the Lua Registry.
This way, when thread 2's socket enters the keepalive state, it will
respect the previous call to `ngx_http_lua_socket_free_pool` (which
unset the pool from the registry).
[1]: https://github.com/openresty/lua-resty-redis/blob/master/t/bugs.t
zhuizhuhaomeng
pushed a commit
that referenced
this pull request
Oct 19, 2021
==openresty==70603==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x621000001500,0x621000002181) and [0x62100000187f, 0x621000002500) overlap
#0 0x7f3db1899ffe (/lib64/libasan.so.5+0x99ffe)
#1 0x9da926 (/usr/local/openresty-debug/nginx/sbin/nginx+0x9da926)
#2 0x9dd1a1 (/usr/local/openresty-debug/nginx/sbin/nginx+0x9dd1a1)
#3 0x4c89c6 (/usr/local/openresty-debug/nginx/sbin/nginx+0x4c89c6)
#4 0x5d1e4e (/usr/local/openresty-debug/nginx/sbin/nginx+0x5d1e4e)
#5 0x4c89c6 (/usr/local/openresty-debug/nginx/sbin/nginx+0x4c89c6)
#6 0x5b8583 (/usr/local/openresty-debug/nginx/sbin/nginx+0x5b8583)
#7 0x4c89c6 (/usr/local/openresty-debug/nginx/sbin/nginx+0x4c89c6)
#8 0x4b4419 (/usr/local/openresty-debug/nginx/sbin/nginx+0x4b4419)
#9 0x427f16 (/usr/local/openresty-debug/nginx/sbin/nginx+0x427f16)
#10 0x7f3daff27554 (/lib64/libc.so.6+0x22554)
#11 0x42d537 (/usr/local/openresty-debug/nginx/sbin/nginx+0x42d537)
xiaocang
pushed a commit
to xiaocang/lua-nginx-module
that referenced
this pull request
Jul 11, 2024
…t_peer at function end.
Avoid inserting new parameters in the middle of the function to prevent core
dumps when using old lua-resty-core with new lua-nginx-module.
Example stack trace:
```
Message: Process 1414245 (nginx) of user 1000 dumped core.
Stack trace of thread 1414245:
#0 0x00007ff596938285 __strlen_avx2 (libc.so.6 + 0x162285)
openresty#1 0x00007ff596f623d2 lj_cf_ffi_string (libluajit-5.1.so.2 + 0x523d2)
openresty#2 0x00007ff596f1bb4b lj_BC_FUNCC (libluajit-5.1.so.2 + 0xbb4b)
openresty#3 0x00007ff596f74223 lua_pcall (libluajit-5.1.so.2 + 0x64223)
openresty#4 0x00000000005044b7 n/a (/home/jiahao/work/org/lua-resty-core/work/nginx/sbin/nginx + 0x1044b7)
```
xiaocang
pushed a commit
to xiaocang/lua-nginx-module
that referenced
this pull request
Jul 11, 2024
…t_peer at function end.
Avoid inserting new parameters in the middle of the function to prevent core
dumps when using old lua-resty-core with new lua-nginx-module.
Example stack trace:
```
Message: Process 1414245 (nginx) of user 1000 dumped core.
Stack trace of thread 1414245:
#0 0x00007ff596938285 __strlen_avx2 (libc.so.6 + 0x162285)
openresty#1 0x00007ff596f623d2 lj_cf_ffi_string (libluajit-5.1.so.2 + 0x523d2)
openresty#2 0x00007ff596f1bb4b lj_BC_FUNCC (libluajit-5.1.so.2 + 0xbb4b)
openresty#3 0x00007ff596f74223 lua_pcall (libluajit-5.1.so.2 + 0x64223)
openresty#4 0x00000000005044b7 n/a (/home/jiahao/work/org/lua-resty-core/work/nginx/sbin/nginx + 0x1044b7)
```
zhuizhuhaomeng
pushed a commit
to xiaocang/lua-nginx-module
that referenced
this pull request
Jul 12, 2024
…t_peer at function end.
Avoid inserting new parameters in the middle of the function to prevent core
dumps when using old lua-resty-core with new lua-nginx-module.
Example stack trace:
```
Message: Process 1414245 (nginx) of user 1000 dumped core.
Stack trace of thread 1414245:
#0 0x00007ff596938285 __strlen_avx2 (libc.so.6 + 0x162285)
openresty#1 0x00007ff596f623d2 lj_cf_ffi_string (libluajit-5.1.so.2 + 0x523d2)
openresty#2 0x00007ff596f1bb4b lj_BC_FUNCC (libluajit-5.1.so.2 + 0xbb4b)
openresty#3 0x00007ff596f74223 lua_pcall (libluajit-5.1.so.2 + 0x64223)
openresty#4 0x00000000005044b7 n/a (/home/jiahao/work/org/lua-resty-core/work/nginx/sbin/nginx + 0x1044b7)
```
xiaocang
pushed a commit
to xiaocang/lua-nginx-module
that referenced
this pull request
Jul 15, 2024
…t_peer at function end.
Avoid inserting new parameters in the middle of the function to prevent core
dumps when using old lua-resty-core with new lua-nginx-module.
Example stack trace:
```
Message: Process 1414245 (nginx) of user 1000 dumped core.
Stack trace of thread 1414245:
#0 0x00007ff596938285 __strlen_avx2 (libc.so.6 + 0x162285)
openresty#1 0x00007ff596f623d2 lj_cf_ffi_string (libluajit-5.1.so.2 + 0x523d2)
openresty#2 0x00007ff596f1bb4b lj_BC_FUNCC (libluajit-5.1.so.2 + 0xbb4b)
openresty#3 0x00007ff596f74223 lua_pcall (libluajit-5.1.so.2 + 0x64223)
openresty#4 0x00000000005044b7 n/a (/home/jiahao/work/org/lua-resty-core/work/nginx/sbin/nginx + 0x1044b7)
```
xiaocang
pushed a commit
to xiaocang/lua-nginx-module
that referenced
this pull request
Aug 1, 2024
…t_peer at function end.
Avoid inserting new parameters in the middle of the function to prevent core
dumps when using old lua-resty-core with new lua-nginx-module.
Example stack trace:
```
Message: Process 1414245 (nginx) of user 1000 dumped core.
Stack trace of thread 1414245:
#0 0x00007ff596938285 __strlen_avx2 (libc.so.6 + 0x162285)
openresty#1 0x00007ff596f623d2 lj_cf_ffi_string (libluajit-5.1.so.2 + 0x523d2)
openresty#2 0x00007ff596f1bb4b lj_BC_FUNCC (libluajit-5.1.so.2 + 0xbb4b)
openresty#3 0x00007ff596f74223 lua_pcall (libluajit-5.1.so.2 + 0x64223)
openresty#4 0x00000000005044b7 n/a (/home/jiahao/work/org/lua-resty-core/work/nginx/sbin/nginx + 0x1044b7)
```
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.