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:[email protected]] > Sent: Wednesday, October 14, 2009 5:54 AM > To: John Lauro > Cc: [email protected] > 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
