Welcome! Log In Create A New Profile

Advanced

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

May 14, 2010 08:50AM
On Fri, May 14, 2010 at 04:39:47PM +0400, Maxim Dounin wrote:

> Hello!
>
> On Fri, May 14, 2010 at 01:31:23PM +0400, Igor Sysoev wrote:
>
> > On Wed, May 05, 2010 at 01:18:53PM +0400, Maxim Dounin wrote:
> >
> > > Hello!
> > >
> > > On Wed, May 05, 2010 at 11:38:41AM +0400, Igor Sysoev wrote:
> > >
> > > > On Tue, May 04, 2010 at 10:38:20AM +0800, agentzh wrote:
> > > >
> > > > > On Tue, May 4, 2010 at 3:11 AM, Igor Sysoev <igor@sysoev.ru> wrote:
> > > > > >
> > > > > > You should test u->cleanup before *u->cleanup = NULL.
> > > > > > This code has appeared in 0.8.33:
> > > > > >
> > > > >
> > > > > Hi, Igor,
> > > > >
> > > > > It is *YOU* who didn't test u->cleanup before *u->cleanup in
> > > > > ngx_http_upstream_create ;)
> > > > >
> > > > > Please read my patch more carefully. To emphasize, in
> > > > > ngx_http_upstream_create, the ngx_http_upstream_cleanup call first
> > > > > clears u->cleanup but you later set *u->cleanup to NULL, which leads
> > > > > to segfault.
> > > > >
> > > > > There's no code written by myself, all in your nginx core ;)
> > > > >
> > > > > I don't see how it is relevant to your fastcgi fixes in 0.8.33. This
> > > > > bug appeared at least in nginx 0.8.29 :)
> > > >
> > > > Yes, thank you, this is my fault.
> > > > Strangely, I did not see segfaults on my production servers.
> > >
> > > I believe this codepath can't be triggered in official nginx.
> >
> > It may trigger if you use something like this:
> >
> > location / {
> > proxy/fastcgi/memcached_pass
> > error_page 404 502 503 = @fallback;
> > }
> >
> > location @fallback {
> > proxy/fastcgi/memcached_pass
> > }
>
> How? Every code path in upstream module I could see (including
> early errors and ngx_http_upstream_intercept_errors()) calls
> ngx_http_upstream_finalize_request() which will clear u->cleanup.
>
> The only idea I have is something like error 400 due to client closed
> connection after POST with proxy_ignore_client_abort on; directed
> to proxied location, but this is due to bug in
> proxy_ignore_client_abort implementation.

The cache should be enabled in the first location:

location / {
proxy/fastcgi_pass
error_page 404 502 503 = @fallback;
proxy_cache_valid 404 502 504 1m;
}

location @fallback {
proxy/fastcgi_pass
}


--
Igor Sysoev
http://sysoev.ru/en/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

[PATCH] Fixing an obvious segfault in ngx_http_upstream

agentzh 2719 April 30, 2010 11:46PM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Igor Sysoev 1085 May 03, 2010 03:12PM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

agentzh 1044 May 03, 2010 10:40PM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Igor Sysoev 1159 May 05, 2010 03:40AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

agentzh 1156 May 05, 2010 03:46AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Maxim Dounin 1051 May 05, 2010 05:20AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Igor Sysoev 1101 May 14, 2010 05:32AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Maxim Dounin 1012 May 14, 2010 08:40AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

Igor Sysoev 1200 May 14, 2010 08:50AM

Re: [PATCH] Fixing an obvious segfault in ngx_http_upstream

agentzh 1287 June 07, 2010 05:40AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 259
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready