-
Notifications
You must be signed in to change notification settings - Fork 18k
net/http/httptest: (*Server).Close races with HTTP/2 request handler #38370
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
Comments
Change https://golang.org/cl/227924 mentions this issue: |
See previously #12262. |
Curiously, I'm not able to get the test to fail without the race detector. I suspect that |
@bcmills Could this be related to the same issue as #36946? Looks like the httptest server's https://golang.org/src/net/http/httptest/server.go?s=5496:5520#L190 I believe that might explain why the test server is not waiting for the handler to complete when HTTP/2 is enabled. |
Too late for 1.15, and not entirely clear that there is a real problem. Moving to Backlog. |
Oh, neat! The regression test in https://go.dev/cl/227924 actually still fails. |
(attn @neild) |
Interesting! The race that is now reported is entirely on the client side. 🤔
|
Ah, that race is #60041. |
In fact, I don't think there's anything in
This doesn't look like a race condition; there just isn't anything that waits for handlers to exit. Perhaps there should be. |
Per https://pkg.go.dev/net/http#Handler:
To me, that makes the phrase “blocks until all outstanding requests on this server have completed” completely unambiguous: a (server-side) request is not “completed” until its handler has returned. |
Change https://go.dev/cl/539436 mentions this issue: |
This also allows us to remove the chanWriter helper from the test, using a simpler strings.Builder instead, relying on clientServerTest.close for synchronization. (I don't think this runs afoul of golang#38370, because the handler functions themselves in these tests should never be executed, let alone result in an asynchronous write to the error log.) Fixes golang#57599. Change-Id: I45c6cefca0bb218f6f9a9659de6bde454547f704 Reviewed-on: https://go-review.googlesource.com/c/go/+/539436 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…ndServerSharedBodyRace This race was reported in https://build.golang.org/log/6f043170946b665edb85b50804a62db68348c52f. As best as I can tell, it is another instance of golang#38370. The deferred call to backend.close() ought to be enough to ensure that the t.Logf happens before the end of the test, but in practice it is not, and with enough scheduling delay we can manage to trip the race detector on a call to Logf after the test function has returned. Updates golang#38370. Change-Id: I5ee45df45c6bfad3239d665df65a138f1c4573a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/531195 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
While investigating #37669, I saw a reported race that led me to believe that, contrary to its documentation,
(*httptest.Server).Close
was not blocking for requests to complete.To check that hypothesis, I added the following test function:
It reliably fails under the race detector with even a very modest count, indicating that the server is not waiting for the handler to complete when HTTP/2 is enabled:
CC @bradfitz @tombergan @nerd2
The text was updated successfully, but these errors were encountered: