commit e9f69c10197f5ca3f834477952654d25c3ff5ecb
author Roman Arutyunyan <arut@nginx.com> Wed Jun 14 20:13:41 2017 +0300
committer Roman Arutyunyan <arut@nginx.com> Wed Jun 14 20:13:41 2017 +0300
tree 4d1c6afd7a7216dd7b9ba3d89004ac1491222ce5
parent 9f1b1b42cc59961d72ca467170a7476c6f825374

Upstream: fixed running posted requests (ticket #788).

Previously, the upstream resolve handler always called
ngx_http_run_posted_requests() to run posted requests after processing the
resolver response.  However, if the handler was called directly from the
ngx_resolve_name() function (for example, if the resolver response was cached),
running posted requests from the handler could lead to the following errors:

- If the request was scheduled for termination, it could actually be terminated
in the resolve handler.  Upper stack frames could reference the freed request
object in this case.

- If a significant number of requests were posted, and for each of them the
resolve handler was called directly from the ngx_resolve_name() function,
posted requests could be run recursively and lead to stack overflow.

Now ngx_http_run_posted_requests() is only called from asynchronously invoked
resolve handlers.

src/http/ngx_http_upstream.c

diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
index 324c59b..8207608 100644
--- a/src/http/ngx_http_upstream.c
+++ b/src/http/ngx_http_upstream.c
@@ -1143,11 +1143,14 @@
 static void
 ngx_http_upstream_resolve_handler(ngx_resolver_ctx_t *ctx)
 {
+    ngx_uint_t                     run_posted;
     ngx_connection_t              *c;
     ngx_http_request_t            *r;
     ngx_http_upstream_t           *u;
     ngx_http_upstream_resolved_t  *ur;
 
+    run_posted = ctx->async;
+
     r = ctx->data;
     c = r->connection;
 
@@ -1211,7 +1214,9 @@
 
 failed:
 
-    ngx_http_run_posted_requests(c);
+    if (run_posted) {
+        ngx_http_run_posted_requests(c);
+    }
 }