Open bcmills opened 1 year ago
Given that it's on windows
, I wonder if this is related to https://go.dev/cl/495875 / #23366.
(attn @qmuntal; CC @golang/windows)
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
Given that it's on windows, I wonder if this is related to https://go.dev/cl/495875 / https://github.com/golang/go/issues/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?
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.)
Two more on https://go.dev/cl/529095:
(CC @golang/release)
From https://ci.chromium.org/ui/p/golang/builders/try-workers/gotip-windows-amd64-test_only/b8770051282862599649/overview:
See previously #19519.
(CC @ianlancetaylor @neild)