Hi James, On Tue, Aug 02, 2016 at 06:25:22PM +0000, James Hartshorn wrote: > Thanks for the info, I had neglected to check if ubuntu provided zlib. > > ldd /usr/sbin/haproxy > linux-vdso.so.1 => (0x00007ffe4ed80000) > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fc9e975f000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc9e955b000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc9e9196000) > /lib64/ld-linux-x86-64.so.2 (0x00007fc9e9998000) > > Here's how I've been building zlib: > > cd /opt > export ZLIB_VERSION=1.2.8 > > tar -xzvf zlib-$ZLIB_VERSION.tar.gz > > cd /opt/zlib-$ZLIB_VERSION > make clean > ./configure --static > make > > And the relevant section of the haproxy make: > > USE_ZLIB=1 ZLIB_INC=/opt/zlib-$ZLIB_VERSION/ ZLIB_LIB=/opt/zlib-$ZLIB_VERSION/ > > > Today we will try building with os provided zlib, and also running without > compression and possibly building without zlib.
Thanks for all the useful info. We already had another one reported, with zlib-1.2.3 + haproxy-1.6.4 on CentOS 6.7, all packages up to date. It appeared it was dying in memcpy() called from zlib. I'm wondering if anything changed recently in the way zlib does its buffer management (ie: maybe they slightly inflated the buffers for various maintenance and the current allocator now returns too small ones). 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. For now we only have two reports of crashes with compression and they are fairly recent, so we can suspect a change in zlib that triggered the issue. thanks! Willy
