On Tue, Aug 21, 2018 at 10:55:40PM +0200, Cyril Bonté wrote:
> > > OK, that one is my fault, I used a "listen" section for use_backend (maybe
> > > we'll have to secure such configuration error to prevent segfaults).
> >
> > I don't see how it could be an issue, that's a completely supported
> > config! You can even have this :
> >
> > listen a
> > use_backend b if { prefer_b }
> >
> > listen b
> > use_backend a if { prefer_a }
> >
> > So any reproducer would be interesting.
>
> I could extract this minimal configuration to reproduce the issue:
> defaults
> mode http
>
> listen proxy1
> bind :9001
> http-request set-header X-Forwarded-Proto http
> http-request capture hdr(X-Forwarded-Proto) len 8
>
> listen proxy2
> bind :9002
> use_backend proxy1
>
> then, curl http://localhost:9002/ will cause a segfault.
Very interesting! Even 1.6 crashes on it! Even with proxy2 being a pure
frontend it dies. Apparently it seems caused by the http-request capture
rule that uses some space that ought to have been allocated in the frontend
but was not. The rule is accepted since proxy1 is a full proxy. Apparently
"capture request header" doesn't die, so it is able to protect itself against
this. I'll have a look to see how to do the same for http-request capture.
> > > The good news : I kept a configuration with abns, but removed the proxy
> > > protocol. Everything is working as expected. So, the proxy protocol looks
> > > to have a main role in the buffer issue.
> >
> > Thanks for the diag. I don't remember changing anything around the proxy
> > protocol, but it's possible that something subtle changed. Also it's not
> > on the regular send/receive path so maybe I overlooked certain parts and
> > broke it by accident when changing the buffers.
> >
> > Same here, if you have a small reproducer it will really help.
>
> I try to find a configuration that could help identify the issue, but
> currently I fail (timings seems to have a role). I let you know once I have
> a good reproducer.
OK thank you!
Willy
