Willy, Can you take me off of this list?
Unsubscribing doesn't work. I have no idea why. I've tried many times. The last time I tried, I got back a message that gmail was identified as a spammer. Here is a sample of my unsubscribe message: ----- snip ---- MIME-Version: 1.0 Received: by 10.140.86.244 with HTTP; Thu, 9 Jan 2014 19:38:56 -0800 (PST) Date: Thu, 9 Jan 2014 22:38:56 -0500 Delivered-To: timprepsc...@gmail.com Message-ID: <CAAJ3AvX7XuqRAQkDGZ4k8DqVDsp2Mt=2mnwsyrhsvnb_bwh...@mail.gmail.com> Subject: unsubscribe From: Tim Prepscius <timprepsc...@gmail.com> To: haproxy+unsubscr...@formilux.org Content-Type: text/plain; charset=ISO-8859-1 unsubscribe ----- snip ---- Thank you, -tim On 1/13/14, Willy Tarreau <w...@1wt.eu> wrote: > 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 > > >
