Thank you so much for your investigation!
We have been running the patch in high volume testing all day and so far it is working fine with no segfaults. ________________________________ From: Willy Tarreau <[email protected]> Sent: Monday, August 8, 2016 8:24:29 AM To: James Hartshorn Cc: Lukas Tribus; [email protected]; Sasha Litvak Subject: Re: Haproxy 1.6.7 segmentation fault under load Hi guys, On Thu, Aug 04, 2016 at 07:02:50PM +0200, Lukas Tribus wrote: > > It may be very useful to build with libslz instead of building without > > zlib. It would stress the exact same code paths in haproxy, you would > > still get compression and we'd see if the issue can be reproduced. > > While googling around I found another report [3], a similar/same crash in > memcpy() while using zlib. Apparently switching to libslz fixed the issue > for them. Now I have found :-) Thanks to the 3 reports we have accumulated, I noticed that we were each time flushing the pending data. And the flush function doesn't set next_in nor avail_in before calling deflate(), probably because it doesn't seem necessary (given the low crash rate I'd argue it rarely is). But when reading the zlib code, it was obvious to me that these ones could be used, to the point that I could force the crash by setting them to some junk. The reason why we didn't get this in 1.5 is that during 1.5 a buffer was assigned to the same session during all its life, so by not setting the values there, we in fact used to leave the earlier ones in place pointing to a valid location. Since we introduced dynamic buffers in 1.6, this is no longer true and buffers can vanish at any moment. Thus I'd encourage those still facing the bug to apply the attached patch and to report their experience. It works on both 1.7 and 1.6. Regards, Willy
