iperf
iperf copied to clipboard
crash with buffer overflow when more than 1024 files open
NOTE: The iperf3 issue tracker is for registering bugs, enhancement requests, or submissions of code. It is not a means for asking questions about building or using iperf3. Those are best directed towards the Discussions section for this project at https://github.com/esnet/iperf/discussions or to the iperf3 mailing list at [email protected]. A list of frequently-asked questions regarding iperf3 can be found at http://software.es.net/iperf/faq.html.
Context
iperf3 --version iperf 3.16-beta1 (cJSON 1.7.15) Linux xxx 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2 x86_64 Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment, POSIX threads
Bug Report
-
Expected Behavior In a system with more than 1024 open files, iperf3 still works
-
Actual Behavior iperf3 crashes with "*** buffer overflow detected ***: terminated"
#9 0x00007fc37189f90c in iperf_connect (test=test@entry=0x559ba8cc0c10) at iperf_client_api.c:431 431 FD_SET(test->ctrl_sck, &test->read_set);
-
Steps to Reproduce keep more than 1024 files open, run iperf3 as client
-
Possible Solution move from select() to poll() or something else that is not limited to a static FD_SETSIZE parameter
Could you provide us with the client command you used for this? Is the system itself running out of file descriptors?
The client uses iperf as a library (which works really great) and unfortunately needs a lot of open sockets which are not directly related to the iperf_run_client() call. It is trivial to raise the max file descriptor limit with ulimit -n, but as soon as the numerical value of a socket goes beyond FD_SETSIZE, FD_SET() creates a buffer overflow. I can work around this by creating a separate process and close those sockets before doing iperf_run_client(), but I think iperf3 can do better than crashing.
To avoid crashing, iperf3 could check the fd numerical value each time before calling FD_SET() and exit with an error if it exceeds FD_SETSIZE. Would not help me, but at least the next user who stumbles over this would know what's the problem
Alternatively, iperf3 could simply switch to poll(). As iperf3 does not use many sockets itself, epoll() or related libraries would be overkill.
The select() API is from a long-gone era where 1000 open sockets seemed more than plenty.
(reopened as I accidentally marked this as closed)