crypto/tls conn sometimes hangs when calling tls.Handshake()

[dannin]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.7.3 linux/amd64

What operating system and processor architecture are you using (go env)?

go version go1.7 linux/amd64
parallels@ubuntu:~/dev/go/bin$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/parallels/dev/go"
GORACE=""
GOROOT="/home/parallels/go"
GOTOOLDIR="/home/parallels/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build353701976=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

Attempted to connect to a websocket server.
Overtime, if the server goes down or is unreachable, the attempt to reconnect can hang.
Connection hangs indefinitely when I attempt to connect to a websocket server. It hangs when going through the line below
https://github.com/gorilla/websocket/blob/master/client.go#L331
*note my stack trace points to an older version at line 307 in gorilla

What did you expect to see?

A timeout atleast if the handshake takes too long

What did you see instead?

Hang of the connect. Stack trace below

goroutine 5177739 [IO wait, 3658 minutes]:
net.runtime_pollWait(0x7fae11ebe220, 0x72, 0x11)
gosrc/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc4204a2a70, 0x72, 0xc4207250c0, 0xc420010140)
gosrc/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc4204a2a70, 0xec0cc0, 0xc420010140)
gosrc/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc4204a2a10, 0xc4201a6000, 0x800, 0x800, 0x0, 0xec0cc0, 0xc420010140)
gosrc/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc420426e10, 0xc4201a6000, 0x800, 0x800, 0x0, 0x0, 0x0)
gosrc/src/net/net.go:173 +0x70
crypto/tls.(*block).readFromUntil(0xc4204ca6c0, 0x7fae11ebe308, 0xc420426e10, 0x5, 0xc420426e10, 0x4176ff)
gosrc/src/crypto/tls/conn.go:476 +0x91
crypto/tls.(*Conn).readRecord(0xc420103500, 0x514, 0xc4204cb1a0, 0x30)
gosrc/src/crypto/tls/conn.go:578 +0xc4
crypto/tls.(*clientHandshakeState).readFinished(0xc420725710, 0xc4201035de, 0xc, 0xc, 0x0, 0x0)
gosrc/src/crypto/tls/handshake_client.go:635 +0x50
crypto/tls.(*Conn).clientHandshake(0xc420103500, 0xa62758, 0xc420103608)
gosrc/src/crypto/tls/handshake_client.go:244 +0x10ee
crypto/tls.(*Conn).Handshake(0xc420103500, 0x0, 0x0)
gosrc/src/crypto/tls/conn.go:1260 +0x1b8
stash.teslamotors.com/STST/tools/vendor/github.com/gorilla/websocket.(*Dialer).Dial(0xc420326b90, 0xc4207a3bc0, 0x30, 0xc4207a3b00, 0x0, 0x0, 0x0, 0x0)
go/src/stash.teslamotors.com/STST/tools/vendor/github.com/gorilla/websocket/client.go:307 +0x1380

[bradfitz]

If the underlying connection has no timeouts (deadlines), then Handshake won't time out.

I'm not sure there's anything to fix here. If you write programs interacting with the network, you have to be pretty defensive about the network being flaky and slow. But opinions on what is slow differ.

[dannin]

@bradfitz there is a dialtimeout of 30seconds, I've created a ticket with in the gorilla project as well to see if it's a bug there.
gorilla/websocket#179

[bradfitz]

If the DialTimeout is on the underlying TCP dial, that doesn't affect the TLS handshake's Read/Write at all.