Comment 1:

Your example code does not compile. Did you paste the correct version ?

Status changed to WaitingForReply.

Comment 2 by coocood:

I pasted to play.golang.org from my local file and forgot to import package.
Here is the correct one
http://play.golang.org/p/T4FsbNsqkc

Comment 3:

interesting, could you please show/tell us;
- the output of attached tcpinfo.go on your environment that happens your issue (you
need to run "go get github.com/mikioh/tcp" first),
- outputs of all routing information by using iproute2 (ip r/n/l/a) or similar command
(pls don't forget to anonymize your private identifiers such as mac64/eui64 addresses),
- how did you verify that address (100.100.100.100) is a non-existent address on your
environment, your ip packet routing domain.

Attachments:

1. tcpinfo.go (487 bytes)

Comment 4 by coocood:

The address is randomly picked, I've tried other addresses, any non-existent address
will do.
my 'ip r' output is :
fe80::21f1:62c0:1c01:76a1 dev eth0 lladdr a4:1f:72:6b:52:e9 router STALE
10.12.104.1 dev wlan0 lladdr 44:2b:03:7d:15:4a STALE
10.12.113.1 dev eth0 lladdr 44:2b:03:7d:15:53 REACHABLE
the output of tcpinfo.go is like:
dial tcp 100.100.100.100:10000: i/o timeout
dial tcp 100.100.100.100:10000: i/o timeout
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m58.388s LastDataReceived:4h31m58.388s LastAckReceived:4h31m58.388s
CC:0xc20800ec00 SysInfo:0xc208018870}
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m58.388s LastDataReceived:4h31m58.388s LastAckReceived:4h31m58.388s
CC:0xc20800ecc0 SysInfo:0xc2080188c0}
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m58.388s LastDataReceived:4h31m58.388s LastAckReceived:4h31m58.388s
CC:0xc20800ed80 SysInfo:0xc208018910}
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m58.388s LastDataReceived:4h31m58.388s LastAckReceived:4h31m58.388s
CC:0xc20800ee40 SysInfo:0xc208018960}
dial tcp 100.100.100.100:10000: i/o timeout
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m59.388s LastDataReceived:4h31m59.388s LastAckReceived:4h31m59.388s
CC:0xc20800ef60 SysInfo:0xc2080189b0}
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h31m59.388s LastDataReceived:4h31m59.388s LastAckReceived:4h31m59.388s
CC:0xc20800f020 SysInfo:0xc208018a00}
dial tcp 100.100.100.100:10000: i/o timeout
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h32m0.388s LastDataReceived:4h32m0.388s LastAckReceived:4h32m0.388s
CC:0xc20800f140 SysInfo:0xc208018a50}
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h32m0.388s LastDataReceived:4h32m0.388s LastAckReceived:4h32m0.388s
CC:0xc20800f200 SysInfo:0xc208018aa0}
dial tcp 100.100.100.100:10000: i/o timeout
&{State:syn-sent Options:[] PeerOptions:[] RTT:0 RTTVar:250ms RTO:1s ATO:0
LastDataSent:4h32m1.392s LastDataReceived:4h32m1.392s LastAckReceived:4h32m1.392s
CC:0xc20800f320 SysInfo:0xc208018af0}
...

Comment 5:

nice, pretty interesting, looks like
> State:syn-sent
something similar to half-tcp hole punching happens. which version of linux are you
running? also, if possible, pls let us know the detail of your network environment
configuration (especially for ip-layer: sysctl states, iptables for nat44,
6rd/nat64/xlat for address translations and link-layer) for repro. i just tried to repro
it on freebsd but failed.

Comment 6 by coocood:

This issue was first caught on production environment which is CentOS 6.3.
Our application works like sentinel who detects other application's failure by dialing
its address, if the error is nil, we consider this application is alive.
My local machine is Ubuntu 14.04 which can also reproduce this issue, and I didn't
change any system variable since installed.
So I guess it has nothing to do with linux version or configuration.

Comment 7:

thanks, looping in dmitriy.
dmitriy: in short, on linux, looks like there's some possibility that somewhere in
net.pollDesc.WaitWrite->net.pollDesc.Wait('w')->runtime.runtime_pollWait(..,
'w')->netpollunblock misses to call epoll_wait. can you identify the location?

Comment 8:

i wrote a workaroud cl, https://golang.org/cl/105400043/, as you suggested. can
you try this and report back the result? thanks.

Status changed to New.

Comment 9 by coocood:

I tried this CL, and it fixes this issue.
I hope there will be 1.3.1 release soon.
Thank you.

Comment 10:

glad to hear that but that's a workaround. the heart of this issue is, on linux we
sometimes miss to call epoll_wait. that means that we'll face more disaster when we use
tcp fastopen protocol or similar stuff.

Comment 11 by garton:

I have also hit this same issue.
Is the real issue and fix understood now?
If so, I'll stop debugging this.  If not, I'll carry on and post my findings.

Comment 12 by garton:

It may be obvious already, but in case it helps:
The initial commit that broke this is this:
https://code.google.com/p/go/source/detail?r=5f662f12d550
Reverting the change (against release 1.3) appears to solve the problem for me.  Judging
from the history this possibly re-instates some other issue though.

Comment 13:

a fix; https://golang.org/cl/120820043/
though, not tested on dragonfly (async-connect enabled platform) yet.

Comment 14:

CL https://golang.org/cl/120820043 mentions this issue.

Comment 15:

Labels changed: added release-go1.3.1.

Comment 16:

This issue was closed by revision c0325f5.

Status changed to Fixed.

Comment 17:

Merging with 8426 because the same CL claims to fix both.

Status changed to Duplicate.

Merged into issue #8426.

Comment 18:

Labels changed: added release-none, removed release-go1.3.1.

Comment 19:

This issue was closed by revision 073fc578434b.

Status changed to Fixed.