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
}

> Additionally, it looks like r->main->count++; there will result in
> socket leak (if it will be triggered).

Where ?


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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel