old-openresty icon indicating copy to clipboard operation
old-openresty copied to clipboard

setting a variable from $echo_it results to crashing

Open ovh opened this issue 13 years ago • 2 comments

set $var $echo_it;

results to nginx crashing: 2012/05/02 12:30:13 [notice] 22517#0: signal 17 (SIGCHLD) received 2012/05/02 12:30:13 [alert] 22517#0: worker process 22518 exited on signal 11 2012/05/02 12:30:13 [notice] 22517#0: start worker process 22535 2012/05/02 12:30:13 [notice] 22517#0: signal 29 (SIGIO) received

conf: location = /getFile { echo_foreach_split ',' $filelist set $file $echo_it; echo_subrequest GET '/getFile' -q 'sha256=$file' ; echo_end; }

ovh avatar May 02 '12 10:05 ovh

On Wed, May 2, 2012 at 6:31 PM, baqs [email protected] wrote:

set $var $echo_it;

results to nginx crashing: 2012/05/02 12:30:13 [notice] 22517#0: signal 17 (SIGCHLD) received 2012/05/02 12:30:13 [alert] 22517#0: worker process 22518 exited on signal 11 2012/05/02 12:30:13 [notice] 22517#0: start worker process 22535 2012/05/02 12:30:13 [notice] 22517#0: signal 29 (SIGIO) received

You're using the $echo_it variable at rewrite phase (because ngx_rewrite's set directive runs at the rewrite phase) and it indeed leads to a segfault. I've committed a patch to ngx_echo's git repository to make it evaluate to empty (or "not found", to be more accurate):

https://github.com/agentzh/echo-nginx-module/commit/08d36f31

conf: location = /getFile { echo_foreach_split ',' $filelist set $file $echo_it; echo_subrequest GET '/getFile' -q 'sha256=$file' ; echo_end; }

Your directives in location = /getFile will not run in the order as they are written, because the "set" directive always runs in the rewrite processing phase of nginx while those ngx_echo directives always run in a later phase, i.e., the content phase. So your directives will actually run in the order like below:

set $file $echo_it;
echo_foreach_split ',' $filelist;
echo_subrequest GET '/getFile' -q 'sha256=$file';
echo_end;

This is surely not what you want (but still it should not crash in any event). For more details regarding nginx processing phases, please read our nginx tutorials here:

http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-enuk.html

Thanks! -agentzh

agentzh avatar May 02 '12 13:05 agentzh

On 02/mai - 06:09, agentzh (章亦春) wrote:

On Wed, May 2, 2012 at 6:31 PM, baqs [email protected] wrote:

set $var $echo_it;

results to nginx crashing: 2012/05/02 12:30:13 [notice] 22517#0: signal 17 (SIGCHLD) received 2012/05/02 12:30:13 [alert] 22517#0: worker process 22518 exited on signal 11 2012/05/02 12:30:13 [notice] 22517#0: start worker process 22535 2012/05/02 12:30:13 [notice] 22517#0: signal 29 (SIGIO) received

You're using the $echo_it variable at rewrite phase (because ngx_rewrite's set directive runs at the rewrite phase) and it indeed leads to a segfault. I've committed a patch to ngx_echo's git repository to make it evaluate to empty (or "not found", to be more accurate):

https://github.com/agentzh/echo-nginx-module/commit/08d36f31 ok thx

conf: location = /getFile { echo_foreach_split ',' $filelist set $file $echo_it; echo_subrequest GET '/getFile' -q 'sha256=$file' ; echo_end; }

Your directives in location = /getFile will not run in the order as they are written, because the "set" directive always runs in the rewrite processing phase of nginx while those ngx_echo directives always run in a later phase, i.e., the content phase. So your directives will actually run in the order like below:

set $file $echo_it;
echo_foreach_split ',' $filelist;
echo_subrequest GET '/getFile' -q 'sha256=$file';
echo_end;

This is surely not what you want (but still it should not crash in any event). For more details regarding nginx processing phases, please read our nginx tutorials here:

thanks a lot for your explanations, I'll try to work-around that.

http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-enuk.html

Thanks! -agentzh


Reply to this email directly or view it on GitHub: https://github.com/agentzh/openresty/issues/2#issuecomment-5460919

ovh avatar May 02 '12 13:05 ovh