net: TestVariousDeadlines failure on Windows LUCI builder

[bcmills]

#!watchflakes
post <- pkg == "net" && test == "TestVariousDeadlines" && `connectex: A connection attempted failed`

From https://ci.chromium.org/ui/p/golang/builders/try-workers/gotip-windows-amd64-test_only/b8770051282862599649/overview:

=== RUN   TestVariousDeadlines
=== PAUSE TestVariousDeadlines
=== CONT  TestVariousDeadlines
    timeout_test.go:1003: 1ns 0/1
    timeout_test.go:1019: 1ns 0/1: good timeout after 82.7µs; 0 bytes
    timeout_test.go:1003: 2ns 0/1
    timeout_test.go:1019: 2ns 0/1: good timeout after 891.3µs; 0 bytes
    timeout_test.go:1003: 5ns 0/1
    timeout_test.go:1019: 5ns 0/1: good timeout after 72µs; 0 bytes
    timeout_test.go:1003: 50ns 0/1
    timeout_test.go:1019: 50ns 0/1: good timeout after 833.5µs; 0 bytes
    timeout_test.go:1003: 100ns 0/1
    timeout_test.go:1007: dial tcp 127.0.0.1:56139: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
--- FAIL: TestVariousDeadlines (1.03s)

See previously #19519.

(CC @ianlancetaylor @neild)

[bcmills]

Given that it's on windows, I wonder if this is related to https://go.dev/cl/495875 / #23366.

(attn @qmuntal; CC @golang/windows)

[bcmills]

If I run the test repeatedly on a gomote I appear to be able to drive it into port exhaustion instead. 😅

gopher@GOLANG-BUILDLET C:\workdir\go\src>..\bin\go test net -run=TestVariousDeadlines -
short -failfast -count=1000
--- FAIL: TestVariousDeadlines (0.01s)
    timeout_test.go:1003: 1ns 0/1
    timeout_test.go:1007: dial tcp 127.0.0.1:50212: connectex: Only one usage of each s
ocket address (protocol/network address/port) is normally permitted.
FAIL
FAIL    net     0.038s
FAIL

[qmuntal]

Given that it's on windows, I wonder if this is related to https://go.dev/cl/495875 / #23366.

Still haven't investigated this, but I wonder what makes you think that? That CL is already 4 month old, and this is the first time I see this watchflakes report. Has something changed in between that could make a latent bug introduced in CL 495875 easier to reproduce?

[bcmills]

Has something changed in between that could make a latent bug introduced in CL 495875 easier to reproduce?

The LUCI builders are running on different machines, slightly different configurations, and perhaps different VM images from the older dashboard builders. It is possible that some variation in either the configuration or timing has exposed a bug.

(It is also possible that some aspect of the LUCI builder configuration is subtly wrong, or perhaps something else on the machine is somehow interfering with the test.)

[bcmills]

Two more on https://go.dev/cl/529095:

• https://ci.chromium.org/ui/p/golang/builders/try-workers/gotip-windows-amd64-test_only/b8769602798783223297/test-results?sortby=&groupby=
• https://ci.chromium.org/ui/p/golang/builders/try/gotip-windows-amd64/b8769603072297519617/test-results?sortby=&groupby=

(CC @golang/release)