2e0cd2aef5
TestVariousDeadlines starts a client and server. The client dials the server, sets a timeout on the connection, reads from it, gets a timeout error, closes the connection. The server writes an infinite stream of a's to each connection it accepts. The test was trying to run these in lockstep: run a client dial+read+timeout+close, wait for server to accept+write+error out on write to closed connection, repeat. On FreeBSD 11.2 and less frequently on macOS we see the test timeout waiting for the server to do its half of the lockstep dance. I believe the problem is that the client can do its step of the dance with such a short timeout that the read, timeout, and close happens before the server ever returns from the accept(2) system call. For the purposes of testing the client-side read timeout, this is fine. But I suspect that under some circumstances, the "TCP-accepted" connection does not translate into a "socket-layer-accepted" connection that triggers a return from accept(2). That is, the Go server never sees the connection at all. And the test sits there waiting for it to acknowledge being done with a connection it never started with. Fix the problem by not trying to lockstep with the server. This definitely fixes the flake, since the specific line that was calling t.Fatal is now deleted. This exposes a different flake, seen on a trybot run for an early version of this CL, in which the client's io.Copy does not stop within the time allotted. The problem now is that there is no guarantee that a read beyond the deadline with available data returns an error instead of the available data, yet the test assumes this guarantee, and in fact the opposite is usually true - we don't bother checking the deadline unless the read needs to block. That is, deadlines don't cut off a flood of available data, yet this test thinks they do. This CL therefore also changes the server not to send an infinite flood of data - don't send any data at all - so that the read deadline is guaranteed to be exercised. Fixes #19519. Change-Id: I58057c3ed94ac2aebab140ea597f317abae6e65e Reviewed-on: https://go-review.googlesource.com/c/go/+/184137 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> |
||
|---|---|---|
| .github | ||
| api | ||
| doc | ||
| lib/time | ||
| misc | ||
| src | ||
| test | ||
| .gitattributes | ||
| .gitignore | ||
| AUTHORS | ||
| CONTRIBUTING.md | ||
| CONTRIBUTORS | ||
| LICENSE | ||
| PATENTS | ||
| README.md | ||
| SECURITY.md | ||
| favicon.ico | ||
| robots.txt | ||
README.md
The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 3.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Download and Install
Binary Distributions
Official binary distributions are available at https://golang.org/dl/.
After downloading a binary release, visit https://golang.org/doc/install or load doc/install.html in your web browser for installation instructions.
Install From Source
If a binary distribution is not available for your combination of operating system and architecture, visit https://golang.org/doc/install/source or load doc/install-source.html in your web browser for source installation instructions.
Contributing
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines: https://golang.org/doc/contribute.html
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://golang.org/wiki/Questions for a list of places to ask questions about the Go language.