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

runtime: TestNetpollDeadlock timeout on freebsd-amd64-race #54591

Open
bcmills opened this issue Aug 22, 2022 · 3 comments
Open

runtime: TestNetpollDeadlock timeout on freebsd-amd64-race #54591

bcmills opened this issue Aug 22, 2022 · 3 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Aug 22, 2022

greplogs -l -e 'FAIL: TestNetpollDeadlock .*(?:\n\s.*)*SIGQUIT' --since=2022-06-01
2022-08-18T17:26:17-07cf24b/freebsd-amd64-race

--- FAIL: TestNetpollDeadlock (60.04s)
    testenv.go:468: [/tmp/workdir/tmp/go-build2829729280/testprognet.exe NetpollDeadlock] exit status: exit status 2
    crash_test.go:463: output does not start with "done\n":
        dialing
        SIGQUIT: quit
        PC=0x46403e m=0 sigcode=65537
…

CC @golang/runtime @golang/freebsd

See previously #42500, #35353, #22403, #22280, #22019.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 22, 2022
@prattmic
Copy link
Member

prattmic commented Aug 22, 2022

The expectation is that the connection will be refused immediately. It seems that it is instead hanging (probably to time out with a longer period than our test timeout?).

@bcmills
Copy link
Member Author

bcmills commented Aug 22, 2022

It's probably hanging because some other test on the machine has actually opened that hard-coded port. 😅

(It's a bad test — you can't just go around opening arbitrary ports on a heavily-loaded machine and assuming their behavior!)

@bcmills bcmills added the Testing An issue that has been verified to require only test changes, not just a test failure. label Aug 22, 2022
@bcmills
Copy link
Member Author

bcmills commented Aug 22, 2022

In particular: if something actually opened port 14356 and started listening on it, and filled up the kernel accept buffer without closing the listener (if freebsd even buffers accept operations?), then it seems possible for a Dial of that port to hang indefinitely.

(And if the port was opened by another test process, the spurious connection may well mess with the behavior of that test too.)

@mknyszek mknyszek added this to the Go1.20 milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
Status: Todo
Development

No branches or pull requests

4 participants