-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parameter to not cache lua script #4
Comments
Yes, this is on our TODO list from day #1 :) I wonder if you're interested in joining the development ;) |
maybe you can temp-replace |
I've just implemented the "lua_code_cache" directive in git HEAD. It currently only accepts two values "off" and "on". Apache mod_lua's "stat" mode is not implemented (yet) and may become a TODO. This feature will be included in the next release of ngx_lua. Thanks! |
Thanks to you :) |
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
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
==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)
…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) ```
…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) ```
…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) ```
…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) ```
…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) ```
Hi, this is a feature request.
As I am starting to use the module more seriously, I find it painful to have to restart nginx everytime I modify a lua script when using the module with content_by_lua_file.
In Apache mod_lua, they have the following directive :
LuaCodeCache stat
LuaCodeCache forever
LuaCodeCache never
Maybe having something like that would make things easier for people like me who develop Lua websites on the fly...
Do you think this could be added to the module ?
Thank you.
The text was updated successfully, but these errors were encountered: