Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
14836:38937a8d0911 tip It's not yet reproducible with tip race detector (obtained with experimental version), but the bug is definitely there. At least it can lead to non-deterministic error value returned from (*TCPListener).Accept(), which in turn leads to non-deterministic return value from http.Serve(). I can imagine it makes some tests flaky. WARNING: DATA RACE Write by goroutine 48: net.(*netFD).decref() src/pkg/net/fd_unix.go:382 +0x10b net.(*netFD).Close() src/pkg/net/fd_unix.go:399 +0x11e net.(*TCPListener).Close() src/pkg/net/tcpsock_posix.go:271 +0x64 net/http/httptest.(*historyListener).Close() src/pkg/net/http/httptest/recorder.go:0 +0x48 net/http/httptest.(*Server).Close() src/pkg/net/http/httptest/server.go:153 +0x4e net/http_test.TestRedirectCookiesOnRequest() src/pkg/net/http/client_test.go:325 +0x194 testing.tRunner() src/pkg/testing/testing.go:301 +0x8f Previous read by goroutine 49: net.(*TCPListener).AcceptTCP() src/pkg/net/tcpsock_posix.go:245 +0x87 net.(*TCPListener).Accept() src/pkg/net/tcpsock_posix.go:258 +0x56 net/http/httptest.(*historyListener).Accept() src/pkg/net/http/httptest/server.go:43 +0x72 net/http.(*Server).Serve() src/pkg/net/http/server.go:1088 +0x97 Goroutine 48 (running) created at: testing.RunTests() src/pkg/testing/testing.go:377 +0xb1a testing.Main() src/pkg/testing/testing.go:313 +0xcd main.main() net/http/_test/_testmain.go:301 +0xda runtime.main() src/pkg/runtime/proc.c:248 +0x91 Goroutine 49 (running) created at: net/http/httptest.(*Server).Start() src/pkg/net/http/httptest/server.go:102 +0x3cb net/http/httptest.NewServer() src/pkg/net/http/httptest/server.go:77 +0x4f net/http_test.TestRedirectCookiesOnRequest() src/pkg/net/http/client_test.go:315 +0x62 testing.tRunner() src/pkg/testing/testing.go:301 +0x8f
What is this bug about? Is this about changing TestRedirectCookiesOnRequest or defining the meaning of Accept's return value when a concurrent Close is called? I would hope the latter. I think Accept should return io.EOF or something when a Close comes in, and I'd like to see that documented and tested.
This issue was closed.