Hi again Steve, On Mon, Jan 13, 2014 at 08:44:08AM +0100, Willy Tarreau wrote: > Hi Steve, > > On Fri, Jan 10, 2014 at 02:16:48PM -0800, Steve Ruiz wrote: > > I'm experimenting with haproxy on a centos6 VM here. I found that when I > > specified a health check page (option httpchk GET /url), and that page > > didn't exist, we have a large 404 page returned, and that causes haproxy to > > quickly segfault (seems like on the second try GET'ing and parsing the > > page). I couldn't figure out from the website where to submit a bug, so I > > figure I'll try here first. > > > > Steps to reproduce: > > - setup http backend, with option httpchk and httpcheck expect string x. > > Make option httpchk point to a non-existent page > > - On backend server, set it up to serve large 404 response (in my case, the > > 404 page is 186kB, as it has an inline graphic and inline css) > > - Start haproxy, and wait for it to segfault > > > > I wasn't sure exactly what was causing this at first, so I did some work to > > narrow it down with GDB. The variable values from gdb led me to the cause > > on my side, and hopefully can help you fix the issue. I could not make > > this work with simply a large page for the http response - in that case, it > > seems to work as advertised, only inspecting the response up to > > tune.chksize (default 16384 as i've left it). But if I do this with a 404, > > it seems to kill it. Let me know what additional information you need if > > any. Thanks and kudos for the great bit of software! > > Thanks for all these details. I remember that the http-expect code puts > a zero at the end of the received buffer prior to looking up the string. > But it might be possible that there would be some cases where it doesn't > do it, or maybe it dies after restoring it. Another thing I'm thinking > about is that we're using the trash buffer for many operations and I'm > realizing that the check buffer's size might possibly be larger :-/
I'm a bit puzzled, not only I cannot reproduce the issue, but also I do not see in the code how this could happen, so I must be missing something. Could you please post the output of "strace -tt" on haproxy when it does this ? Especially the last checks ? I'm suspecting an anomaly in the receive buffer size calculation but all I read here seems fine, which puzzles me. Thanks! Willy
