net: dialing a loopback address sometimes fails with `ECONNRESET` on NetBSD

[gopherbot]

#!watchflakes
post <- goos == "netbsd" && `connect: connection reset by peer`

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestFileCloseRace (0.00s)
    file_test.go:321: dial tcp 127.0.0.1:65102: connect: connection reset by peer

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "net" && test == "TestFileCloseRace"

2023-02-02 19:39 netbsd-amd64-9_3 go@fcd0e096 net.TestFileCloseRace (log)

--- FAIL: TestFileCloseRace (0.00s)
    file_test.go:321: dial tcp 127.0.0.1:65102: connect: connection reset by peer

— watchflakes

[bcmills]

@golang/netbsd, this is the first we've seen of this failure mode, and it looks to me like a bug somewhere in the (Go or kernel) network stack.

The handler reads a byte from the connection before closing it, so I don't see why Dial should ever fail with ECONNRESET.
(https://cs.opensource.google/go/go/+/master:src/net/file_test.go;l=306-308;drc=b55cbbb9e76969d67fbc6e264a584ad18c2f95fa)

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "net" && test == "TestFileCloseRace" && `connection reset by peer`

2023-03-24 02:45 netbsd-amd64-9_3 go@33b63480 net.TestFileCloseRace (log)

--- FAIL: TestFileCloseRace (0.01s)
    file_test.go:321: dial tcp 127.0.0.1:64962: connect: connection reset by peer

— watchflakes

[bcmills]

@golang/netbsd, this still looks like a kernel bug to me, and I've found at least two other reports of it (#60743 and #52168).

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- goos == "netbsd" && `connect: connection reset by peer`

2023-05-02 02:52 netbsd-386-9_3 vuln@76abf843 go@c3c53a2c x/vuln/internal/client.TestByModules (log)

--- FAIL: TestByModules (0.55s)
    --- FAIL: TestByModules/all (0.13s)
        --- FAIL: TestByModules/all/http (0.00s)
            client_test.go:277: Get "http://127.0.0.1:65467/index/modules.json.gz": dial tcp 127.0.0.1:65467: connect: connection reset by peer

2023-05-05 20:14 netbsd-amd64-9_3 vuln@d573de52 go@f3034bed x/vuln/internal/client.TestByModules (log)

--- FAIL: TestByModules (0.30s)
    --- FAIL: TestByModules/all (0.12s)
        --- FAIL: TestByModules/all/http (0.00s)
            client_test.go:277: Get "http://127.0.0.1:65468/index/modules.json.gz": dial tcp 127.0.0.1:65468: connect: connection reset by peer

2023-06-01 14:35 netbsd-amd64-9_3 net@10cf3880 go@db3f952b x/net/ipv6.TestConnInitiatorPathMTU (log)

--- FAIL: TestConnInitiatorPathMTU (0.00s)
    sockopt_test.go:40: dial tcp6 [::1]:65509: connect: connection reset by peer
    asm_amd64.s:1650: accept tcp6 [::1]:65509: use of closed network connection

2023-06-08 16:11 netbsd-386-9_3 net@5541298b go@1db23771 x/net/ipv6.TestConnUnicastSocketOptions (log)

--- FAIL: TestConnUnicastSocketOptions (0.00s)
    unicastsockopt_test.go:44: dial tcp6 [::1]:65504: connect: connection reset by peer

— watchflakes

[riastradh]

Is there a reproducer for this? Does ktrace confirm the kernel is actually returning ECONNRESET?