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/http: apparent TestServerAllowsBlockingRemoteAddr flakes due to hard-coded timeouts #36179

Open
bcmills opened this issue Dec 17, 2019 · 1 comment

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Dec 17, 2019

2019-12-16T20:38:31-f7f9866/plan9-386-0intro
2019-06-12T14:58:18-65f53da/plan9-amd64-9front

--- FAIL: TestServerAllowsBlockingRemoteAddr (1.08s)
    serve_test.go:1300: Request 1: Get "http://127.0.0.1:55517": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
    serve_test.go:1349: response 1 addr = ""; want "RA:21.21.21.21:21"
http.test 1018696: warning: process exceeds 100 file descriptors
FAIL
FAIL	net/http	114.189s

As far as I can tell, the root cause is the hard-coded time.Second here:

go/src/net/http/serve_test.go

Lines 1326 to 1330 in 931fe39

select {
case conn2 = <-conns:
case <-time.After(time.Second):
t.Fatal("Second Accept didn't happen")
}

It's not obvious to me why a timeout is needed there at all. If the test deadlocks, we presumably want a goroutine dump anyway.

CC @bradfitz @0intro @fhs

@bcmills

This comment has been minimized.

Copy link
Member Author

@bcmills bcmills commented Dec 17, 2019

That's the regression test for #12943.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.