Hi Willy,
> Chris Allen and Jeff Zellner reported a similar issue at the same > time on two different versions : 1.4.20 and 1.5-dev17. The symptom > is always the same, haproxy suddenly started to crash under load > while it did not in the past. > > When looking deeper into the traces and core files, it happens that > both versions were built with TARGET=generic, so haproxy was using > select() to poll for new events. > > The issue was tracked down to a recent update to glibc which now > verifies that the file descriptor number passed to FD_SET/FD_CLR/ > FD_ISSET is comprised between 0 and FD_SETSIZE-1 (1023) : > > http://repo.or.cz/w/glibc.git/commitdiff/a0f33f996 > > I believe it was merged into glibc 2.16 and backported in the glibc > 2.15 as shipped with Ubuntu 12.04. Sorry to wakeup this one year old thread, I just hit a crash while playing with older code and want to confirm that its 'only' this particular (known) problem I'm hitting, not a hidden bug (or whatever). Your description corresponds with my configuration (using select() with glibc 2.15 on ubuntu crashing with some load). On the terminal I see (which is what confuses a bit): *** buffer overflow detected ***: ./haproxy terminated and the backtrace looks like this: (gdb) backtrace full #0 0xb76e2424 in __kernel_vsyscall () No symbol table info available. #1 0xb755b1df in raise () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #2 0xb755e825 in abort () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #3 0xb759839a in ?? () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #4 0xb76310e5 in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #5 0xb762feba in __chk_fail () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #6 0xb763107a in __fdelt_warn () from /lib/i386-linux-gnu/libc.so.6 No symbol table info available. #7 0x0809ad3f in _do_poll (p=0x80ce0e0, exp=-1820950388) at src/ev_select.c:65 I'm quite sure its exactly this problem, but I prefer to double check with you. Thanks, Lukas
