RE: [ANNOUNCE] haproxy 1.4-dev4 and 1.3.21

valgrind ./haproxy -f /etc/lb.cfg
==8149== Memcheck, a memory error detector
==8149== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==8149== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==8149== Command: ./haproxy -f /etc/lb.cfg
==8149==

[WARNING] 286/084451 (8149) : [./haproxy.main()] Cannot raise FD limit to 40055.
==8149== Invalid read of size 1
==8149== at 0x41620F: uxst_event_accept (proto_uxst.c:469)
==8149== by 0x42DB38: _do_poll (ev_sepoll.c:532)
==8149== by 0x4021C6: run_poll_loop (haproxy.c:926)
==8149== by 0x403843: main (haproxy.c:1203)
==8149== Address 0x19 is not stack'd, malloc'd or (recently) free'd
==8149==
==8149==
==8149== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==8149== Access not within mapped region at address 0x19
==8149== at 0x41620F: uxst_event_accept (proto_uxst.c:469)
==8149== by 0x42DB38: _do_poll (ev_sepoll.c:532)
==8149== by 0x4021C6: run_poll_loop (haproxy.c:926)
==8149== by 0x403843: main (haproxy.c:1203)
==8149== If you believe this happened as a result of a stack
==8149== overflow in your program's main thread (unlikely but
==8149== possible), you can try to increase the size of the
==8149== main thread stack using the --main-stacksize= flag.
==8149== The main thread stack size used in this run was 8388608.
==8149==
==8149== HEAP SUMMARY:
==8149== in use at exit: 3,664,267 bytes in 159 blocks
==8149== total heap usage: 289 allocs, 130 frees, 3,669,374 bytes
allocated
==8149==
==8149== LEAK SUMMARY:
==8149== definitely lost: 0 bytes in 0 blocks
==8149== indirectly lost: 0 bytes in 0 blocks
==8149== possibly lost: 193,987 bytes in 104 blocks
==8149== still reachable: 3,470,280 bytes in 55 blocks
==8149== suppressed: 0 bytes in 0 blocks
==8149== Rerun with --leak-check=full to see details of leaked memory
==8149==
==8149== For counts of detected and suppressed errors, rerun with: -v
==8149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

> -----Original Message-----
> From: Krzysztof Olêdzki [mailto:ole#ans.pl]
> Sent: Wednesday, October 14, 2009 5:54 AM
> To: John Lauro
> Cc: haproxy#formilux.org
> Subject: Re: [ANNOUNCE] haproxy 1.4-dev4 and 1.3.21
> 
> On 2009-10-14 10:47, John Lauro wrote:
> > Sorry to report, from 1.3.21:
> > Oct 13 23:36:43 haf1a kernel: haproxy[25428]: segfault at 19 ip
> > 000000000041620f sp 00007ffff381ef60 error 4 in haproxy[400000+3d000]
> >
> >
> > (I know, kind of old, as we were running 1.3.18 on this box, so not
> sure
> > which version the problem started)
> >
> >
> > Compiled with:
> > make TARGET=linux26 USE_LINUX_TPROXY=1
> >
> > Seems to crash on the standby box too fairly quickly which only
> generates
> > it's own traffic for checks, so it should be easy to reproduce.
> 
> Would it be possible to compile haproxy with -g (normally enabled), and
> run non-stripped binary with valgrind[1]. If the bug is trivial it
> should immediately show where the problem is.
> 
> [1] http://valgrind.org/
> 
> Best regards,
> 
> 			Krzysztof Olêdzki
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.421 / Virus Database: 270.14.11/2430 - Release Date:
> 10/13/09 19:11:00