Hi Lukas, On Thu, Mar 06, 2014 at 09:54:44AM +0100, Lukas Tribus wrote: > Hi Willy, > > > >> 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. > > > > Yes it was the exact same trace I used to get when using select() with > > too large file descriptors. I really think that this glibc change will > > break a large number of software... > > Thanks. Yes, indeed. > > I wonder why it doesn't crash without compiler optimization (-O0) though.
I suspect that the FD_SET macros might be declared as functions instead of macros and that they check the parameter before dereferencing the array. That's just a guess. Willy
