Hello,
On 2009-10-14 15:26, John Lauro wrote:
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/
I was going to look into this, however it seems that Willy had already
fixed this problem in 1.3:
http://haproxy.1wt.eu/git?p=haproxy-1.3.git;a=commitdiff;h=8087c66b3c099c930db96d0af7c47641f18eb51d
Best regards,
Krzysztof Olędzki
