You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 26, 2026. It is now read-only.
There is a race condition in the testsuite related to closing the listener mux.
Due to golang/go#10527 (which may or may not be a bug), calling Listener.Close does not actually close the socket if any goroutines are still blocked in Listener.Accept. This means that after TestSimple finishes, TestMany may run immediately afterwards and try to bind to port 55111 but it can't because the socket from TestSimple hasn't been closed yet.
This can happen by chance on any system, but on uniprocessor systems this is 100% reproducible because the go scheduler always schedules TaskMany first. If you are on Linux, I found that it's easy to reproduce this by hotplugging all but one CPU out.
From: https://bugs.debian.org/851876
There is a race condition in the testsuite related to closing the listener mux.
Due to golang/go#10527 (which may or may not be a bug), calling
Listener.Closedoes not actually close the socket if any goroutines are still blocked inListener.Accept. This means that afterTestSimplefinishes,TestManymay run immediately afterwards and try to bind to port 55111 but it can't because the socket fromTestSimplehasn't been closed yet.This can happen by chance on any system, but on uniprocessor systems this is 100% reproducible because the go scheduler always schedules
TaskManyfirst. If you are on Linux, I found that it's easy to reproduce this by hotplugging all but one CPU out.