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 · 2 comments

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
Copy link
Member Author

@bcmills bcmills commented Dec 17, 2019

That's the regression test for #12943.

@HowJMay
Copy link
Contributor

@HowJMay HowJMay commented Feb 29, 2020

Is this one still one still open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.