Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: TestConnClose failure with "connect: connection refused" on netbsd-arm-bsiegert #52413

Open
bcmills opened this issue Apr 18, 2022 · 3 comments
Labels
arch-arm Issues solely affecting the 32-bit arm architecture. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Apr 18, 2022

--- FAIL: TestConnClose (0.00s)
    --- FAIL: TestConnClose/unix (0.37s)
        net_test.go:194: dial unix /var/gobuilder/buildlet/tmp/2224876548/sock: connect: connection refused
FAIL
FAIL	net	26.230s

greplogs --dashboard -md -l -e 'FAIL: TestConnClose .*(?:\n .*)* connect: connection refused'

2022-04-15T01:08:38-5a4f0b6/netbsd-arm-bsiegert

@bcmills bcmills added OS-NetBSD NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-arm Issues solely affecting the 32-bit arm architecture. labels Apr 18, 2022
@bcmills bcmills added this to the Backlog milestone Apr 18, 2022
@bcmills
Copy link
Contributor Author

bcmills commented Apr 18, 2022

@bsiegert, @coypoop: could this be a bug in the NetBSD implementation of Unix domain sockets?

This test is pretty simple — I don't see any way the test process could not be listening on the socket at that point.

@riastradh
Copy link

This is pretty weird. None of this code is obviously machine-dependent, and we haven't been able to reproduce this in thousands of trials (although I haven't tried a 32-bit arm system). Has this happened more than once?

In case this happens only under parallel tests that use the same file name sock -- I assume the temporary directory selection here is robust to collisions in the random directory name generation, right?

@bcmills
Copy link
Contributor Author

bcmills commented Apr 20, 2022

Has this happened more than once?

Not that I can find.

In case this happens only under parallel tests that use the same file name sock -- I assume the temporary directory selection here is robust to collisions in the random directory name generation, right?

I sure hope so — I just reworked it for exactly that purpose in December! 😅
(See https://go.dev/cl/370694.)

But there may still be a bug remaining there somewhere — I haven't been able to track down the failure in #51441 yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-arm Issues solely affecting the 32-bit arm architecture. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD
Projects
None yet
Development

No branches or pull requests

2 participants