*** buffer overflow detected ***: httperf terminated about httperf

[inevity]

the crash maybe be brough by the commit http://repo.or.cz/w/glibc.git/commitdiff/a0f33f996 include in the glib 1.5 and so on.
maybe we could disable the range check with select, or we switch to poll/epoll.
there is two method to disable the range check 1,-D_FORTIFY_SOURCE=0 in compiling 2,change glibc to selectively disable the range check on linux .

I use the -D_FORTIFY_SOURCE=0 then increase the rate , no crash occurred. but the concurrent connections metric looks like abnormal. i will look into it.

ref
http://www.serverphorums.com/read.php?10,680364
https://sourceware.org/ml/libc-alpha/2013-05/msg00078.html

[oleynikandrey]

Is anybody plan to fix it?

[garysferrao]

I think this bug arises because the compiled kernel system call source code still has "1024" in its select().

A better fix would be to enable connect timeout. httperf wildly assumes that the tester wants the same connect and response timeout. You can avoid the problem of running out of file descriptors by simply closing the connection and freeing up the socket if the connection takes too long to even establish (or if the server is too busy to even refuse the connection)

A connect timeout of 1 second seems reasonable enough. You can choose this value depending on what you want.

You have one of two options:

1. Change both connect and response timeout simultaneously:
   httperf --timeout 1

2. If you only want to change connect timeout, then edit core.c:
   Under SYSCALL(CONNECT, comment out the following line
   if (param.timeout > 0.0)
   Change timer_schedule (conn_timeout, arg, param.timeout); to timer_schedule (conn_timeout, arg, 1.0);
   Recompile and reinstall httperf. That's it. No messing with stupid OS limits and #defines.

Works like a charm.
Thumbs up if this helps!~