net/http: TestTransportAndServerSharedBodyRace_h2 flake

[bradfitz]

http://build.golang.org/log/ee0d84292b89db841915ff25bd6807b2e6c4c536

2016/01/14 06:00:50 http2: server closing client connection; error reading frame from client 127.0.0.1:49824: read tcp 127.0.0.1:49821->127.0.0.1:49824: wsarecv: An established connection was aborted by the software in your host machine.
--- FAIL: TestTransportAndServerSharedBodyRace_h2 (0.16s)
    serve_test.go:3169: Original request: Post https://127.0.0.1:49822: stream error: stream ID 1; STREAM_CLOSED
FAIL
FAIL    net/http    21.824s

[alexbrainman]

I cannot reproduce this failure here.

I can see similar "http2: server closing client connection; ..." message logged, but the test still PASSes. I can uses this:

diff --git a/src/net/http/h2_bundle.go b/src/net/http/h2_bundle.go
index bdbdadb..30b9ba6 100644
--- a/src/net/http/h2_bundle.go
+++ b/src/net/http/h2_bundle.go
@@ -3371,6 +3371,9 @@ func (sc *http2serverConn) processFrameFromReader(res http2readFrameResult) bool
            return true
        }
        clientGone := err == io.EOF || strings.Contains(err.Error(), "use of closed network connection")
+       if !clientGone && runtime.GOOS == "windows" {
+           clientGone = strings.Contains(err.Error(), "An existing connection was forcibly closed by the remote host")
+       }
        if clientGone {

            return false

to get rid of that message.

Alex

[bradfitz]

I also can't reproduce, even with thousands of runs on Windows. Maybe it got fixed in the meanwhile.

But I fixed the log spam in https://go-review.googlesource.com/18932

[gopherbot]

CL https://golang.org/cl/18932 mentions this issue.

[bradfitz]

I got a different kind of flake now after hundreds of runs:

--- PASS: TestTransportAndServerSharedBodyRace_h2 (0.03s)
=== RUN   TestTransportAndServerSharedBodyRace_h2
--- PASS: TestTransportAndServerSharedBodyRace_h2 (0.03s)
=== RUN   TestTransportAndServerSharedBodyRace_h2
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
1 second passes in backend, proxygone= false
--- PASS: TestTransportAndServerSharedBodyRace_h2 (60.01s)
=== RUN   TestTransportAndServerSharedBodyRace_h2
--- PASS: TestTransportAndServerSharedBodyRace_h2 (0.02s)

It passed, but very slowly, after 60 seconds oddly. (What is 60 seconds?)

[gopherbot]

CL https://golang.org/cl/18934 mentions this issue.

[bradfitz]

Reopening for Go 1.7 to track the 60 second timeout thing.

[bradfitz]

This same failure was reported in nacl, at: https://go-review.googlesource.com/#/c/18946/1

[bradfitz]

/cc @evandbrown

[alexbrainman]

I cannot see "http2: server closing client connection; ..." log messages anymore. And the test PASSes too.

Alex

[bradfitz]

Same flake seen on nacl-386:

https://storage.googleapis.com/go-build-log/a2269145/nacl-386_3cd0dba2.log

ok      mime/quotedprintable    0.365s
ok      net 2.100s
--- FAIL: TestTransportAndServerSharedBodyRace_h2 (0.44s)
    serve_test.go:3221: Original request: Post https://127.0.0.1:384: stream error: stream ID 1; STREAM_CLOSED
FAIL
FAIL    net/http    14.733s
ok      net/http/cgi    0.628s

[pwaller]

While browsing a shiny new HTTP2 go server with Google Chrome, I hit a grey Chrome background with SPDY_PROTOCOL_ERROR.

Looking in the server logs I saw these errors:

http: proxy error: stream error: stream ID 95; CANCEL
http: proxy error: stream error: stream ID 99; CANCEL
http: proxy error: stream error: stream ID 123; CANCEL
http: proxy error: client disconnected

I've seen ~75 of these "client disconnected" errors and ~200 "stream error" in something like ~100,000 requests from heterogeneous clients. So perhaps it is a rare bug case?

Since I've managed to hit it myself once, I thought I would try and reproduce it locally with Chrome, but I can't figure out a way of generating lots of requests from Chrome with keepalives disabled. I haven't been able to hit it again with normal use. Any smart ideas there? Otherwise I might try and do it generating the requests from a go client.

[bradfitz]

I think this is almost certainly the same as #15425 which is being fixed by https://golang.org/cl/23287

Closing as dup.