Closed GoogleCodeExporter closed 9 years ago
I was not able to reproduce this. Does anyone else see this behavior?
Original comment by bltier...@es.net
on 26 Nov 2013 at 4:07
Reproduced it quite frequently on RHEL 6.X .
Try running the steps 5/6 times . It's getting reproduced.
strace server :
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072) = 131072
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072) = 131072
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072) = 131072
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072) = 131072
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072) = 131072
write(5,
"\275E\207\265\326\36P\202)An\225x\243\356W\304f\362\370\336\342\206~\365\260\3\
210\366}\325\263"..., 131072 <====================Blocked
Client strace:
gettimeofday({1386164922, 754122}, NULL) = 0
select(5, [3 4], [], NULL, {0, 0}) = 1 (in [4], left {0, 0})
gettimeofday({1386164922, 754171}, NULL) = 0
select(5, [3 4], [], NULL, {0, 0}) = 1 (in [4], left {0, 0})
gettimeofday({1386164922, 754221}, NULL) = 0
select(5, [3 4], [], NULL, {0, 0}) = 1 (in [4], left {0, 0})
gettimeofday({1386164922, 754269}, NULL) = 0
select(5, [3 4], [], NULL, {0, 0}) = 1 (in [4], left {0, 0}
<================== Select getting TMO
iperf_run_client:
After receiving all the test data
1. The client sends TEST_DONE to the server
2. The Server socket is blocked on write. It never able to receive the the TEST_DONE from the control channel.
3. The Client tries to read data and getting TMO and server blocks on write.
it's a dead lock.
There should be some kind of TMO in the write and receive
Wrote a patch which fixes this . Setting socket to some amount of TMO .
SO_RCVTIMEO
SO_SNDTIMEO
Original comment by susant.sahani
on 4 Dec 2013 at 2:13
Attachments:
I can't reproduce this either.
I don't see a TEST_DONE state anywhere in the source. There's TEST_END and
IPERF_DONE. See http://code.google.com/p/iperf/wiki/IperfProtocolStates for
details on the protocol and states.
Original comment by jef.posk...@gmail.com
on 10 Dec 2013 at 2:03
However, one idea to look at is if this happens on lower-speed links. Perhaps
there, the pipe doesn't have time to empty before the receiver closes its read
socket. Its certainly possible this could only happen in reverse mode.
Original comment by jef.posk...@gmail.com
on 10 Dec 2013 at 2:32
yes it's TEST_END . I did a typo there.
#define TEST_END 4
This is no more reproducible because I guess it got fixed by this commit e4d782b488ed
Log message
Fixed bug where -R mode selected on a closed file.
Also added a debugging routine to dump an fd_set.
Affected files expand all collapse all
Modify /src/iperf_server_api.c diff
Modify /src/iperf_util.c diff
Modify /src/iperf_util.h diff
Original comment by susant.sahani
on 10 Dec 2013 at 7:26
Ok! Then let's close this one.
Original comment by jef.posk...@gmail.com
on 10 Dec 2013 at 2:00
Original issue reported on code.google.com by
intra2...@googlemail.com
on 19 Nov 2013 at 3:52Attachments: