It's probably because the test cases, both TestDialTimeout and TestDialTimeoutFDLeak, depend on a wrong assumption with runtime scheduler. Looks like the flakiness in net/http is irrelevant, though.

--- FAIL: TestIdleConnChannelLeak (0.01s)
    transport_test.go:1949: Get http://foo-host-0.tld/: dial tcp 127.0.0.1:44835: getsockopt: connection refused
FAIL
FAIL    net/http    6.978s

@aclements,

Can you give https://golang.org/cl/12691 a shot?

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

I don't really understand why that CL will fix this (or, indeed, what it's really fixing), but I'll update and restart my run.bash loop.

Previously I was able to reproduce this twice in 322 iterations. With this change I've gotten through 1,500 iterations without a failure.

Thanks for the confirmation. The root cause comes from the current corner-cutting socktest package implementation. It tries to track socket calls with socket descriptor numbers as a key for testing, and has no care about "quick socket descriptor number recycling" for simplicity. Therefore it may confuse socket descriptors in a situation like the following:

G1  CALL socket
G1  RET socket = 3
G1  socktest.register(3)
G1  CALL close(3)
G2  CALL socket
G2  RET socket = 3
G2  socktest.register(3) // eviction
G1  RET close
G1  socktest.unregister(3) // eviction
G2  CALL connect(3, ...)
G2  socktest.connect(3, ...) // socktest.switch redirects the call to syscall and results "dial tcp 127.0.0.1:0 getsockopt: connection refused" error

This may happen in selfConnect, in the case of TCP simultaneous open, and Linux is one of the platforms that can make TCP simultaneous open happen easily.