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

Jump to bottom

x/net/http2: apparent deadlock in TestTransportReqBodyAfterResponse_200 #48970

Closed
bcmills opened this issue Oct 14, 2021 · 3 comments
Closed

x/net/http2: apparent deadlock in TestTransportReqBodyAfterResponse_200 #48970

bcmills opened this issue Oct 14, 2021 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.18

Comments

@bcmills
Copy link
Contributor

bcmills commented Oct 14, 2021 •
edited 

goroutine 10680 [semacquire, 9 minutes]:
sync.runtime_Semacquire(0xc000398840)
	/workdir/go/src/runtime/sema.go:56 +0x25
sync.(*WaitGroup).Wait(0xc000047b00)
	/workdir/go/src/sync/waitgroup.go:130 +0x71
golang.org/x/net/http2.(*clientTester).run(0xc0000cc550)
	/workdir/gopath/src/golang.org/x/net/http2/transport_test.go:846 +0x187
golang.org/x/net/http2.testTransportReqBodyAfterResponse(0xc0006bb760, 0xc8)
	/workdir/gopath/src/golang.org/x/net/http2/transport_test.go:1013 +0x17e
golang.org/x/net/http2.TestTransportReqBodyAfterResponse_200(0x10100c000322018)
	/workdir/gopath/src/golang.org/x/net/http2/transport_test.go:885 +0x1e
testing.tRunner(0xc0006024e0, 0x828ef8)
	/workdir/go/src/testing/testing.go:1377 +0x102
created by testing.(*T).Run
	/workdir/go/src/testing/testing.go:1424 +0x35f

It looks like the failure rate got much worse after CL 355491 (CC @neild, @bradfitz), but there were a couple of failures on linux-arm64-packet even before then.

greplogs --dashboard -md -l -e '(?m)goroutine .* \[.*, \d+ minutes\]:\n(.+\n\t.+\n)*golang\.org/x/net/http2\.testTransportReqBodyAfterResponse'

2021-10-14T13:09:28-e13a265-24e798e/linux-amd64-buster
2021-10-14T13:09:28-e13a265-24e798e/linux-amd64-jessie
2021-10-14T13:09:28-e13a265-24e798e/netbsd-386-9_0
2021-10-14T07:19:29-e13a265-2feb2cc/linux-amd64-clang
2021-10-14T07:19:29-e13a265-2feb2cc/linux-amd64-jessie
2021-10-14T07:19:29-e13a265-2feb2cc/linux-amd64-sid
2021-10-14T04:18:44-e13a265-9e4dc6f/illumos-amd64
2021-10-14T04:18:44-e13a265-9e4dc6f/linux-386-jessie
2021-10-14T04:18:44-e13a265-9e4dc6f/linux-ppc64le-buildlet
2021-10-14T01:51:22-e13a265-276fb27/dragonfly-amd64
2021-10-14T01:51:22-e13a265-276fb27/linux-386-clang
2021-10-14T01:51:22-e13a265-276fb27/linux-386-stretch
2021-10-14T01:51:22-e13a265-276fb27/linux-amd64-bullseye
2021-10-14T01:51:22-e13a265-276fb27/linux-ppc64le-buildlet
2021-10-13T20:31:25-e13a265-b90d258/linux-386-buster
2021-10-13T20:31:25-e13a265-b90d258/linux-amd64-clang
2021-10-13T18:15:48-e13a265-40f82f8/dragonfly-amd64
2021-10-13T18:15:48-e13a265-40f82f8/linux-amd64-buster
2021-10-13T18:15:48-e13a265-40f82f8/linux-amd64-jessie
2021-10-13T17:16:12-e13a265-4a3daee/linux-amd64-bullseye
2021-10-13T17:16:12-e13a265-4a3daee/linux-amd64-buster
2021-10-13T17:16:12-e13a265-4a3daee/linux-amd64-sid
2021-10-13T17:16:12-e13a265-4a3daee/linux-ppc64-buildlet
2021-10-13T17:12:55-e13a265-c580180/linux-amd64
2021-10-13T17:12:55-e13a265-c580180/linux-amd64-jessie
2021-10-13T17:12:55-e13a265-c580180/linux-amd64-nocgo
2021-10-13T17:12:55-e13a265-b5904f3/linux-amd64-buster
2021-10-13T17:12:55-e13a265-b5904f3/linux-amd64-fedora
2021-10-13T17:12:55-e13a265-b5904f3/netbsd-386-9_0
2021-09-30T18:10:18-e81a3d9-205640e/linux-arm64-packet
2021-09-27T19:42:34-4e4d966-315cec2/linux-arm64-packet
@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Oct 14, 2021
@bcmills bcmills added this to the Go1.18 milestone Oct 14, 2021
@bcmills
Copy link
Contributor Author

bcmills commented Oct 14, 2021

The linux-amd64-packet failures prior to that CL could plausibly be #48925.

@bcmills
Copy link
Contributor Author

bcmills commented Oct 14, 2021 •
edited

Looks like there is a fix for this pending in CL 355649.

@gopherbot
Copy link

Change https://golang.org/cl/355649 mentions this issue: http2: deflake TestTransportReqBodyAfterResponse_200

@bcmills bcmills mentioned this issue Nov 3, 2021
Closed
dteh pushed a commit to dteh/fhttp that referenced this issue Jun 22, 2022
@neild
http2: deflake TestTransportReqBodyAfterResponse_200
2b5f495 
Don't send the END_STREAM flag from the server until the client
sends its END_STREAM. Avoids a flaky failure when the client
sends the END_STREAM in a zero-length DATA frame:

  - The server reads bodySize bytes and half-closes the stream.
  - The client's Response.Body returns EOF.
  - The test calls Response.Body.Close.
  - The client resets the stream.

Avoid hanging forever on the client side of the test if the
server side exits with an error.

Fixes golang/go#48970

Change-Id: Ic921a3f60149abbb5434ec7a53985becea7b23c3
Reviewed-on: https://go-review.googlesource.com/c/net/+/355649
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@golang golang locked and limited conversation to collaborators Oct 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
2 participants
@bcmills @gopherbot