This probably fixes the failure mode seen in
https://build.golang.org/log/e73acfd930cbe82302505cac0041d9883e2360c5.
If not, allowing the test to deadlock and dump goroutines
should produce better debugging information than the existing
"didn't return in an expected time" failure message.
For #58901.
Change-Id: Ie0bb1887a4329d2f6b0e7348a4820af71385494e
Reviewed-on: https://go-review.googlesource.com/c/go/+/548881
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
To get them to pass, implement more fake syscalls.
To make those syscalls easier to reason about, replace
the use of sync.Cond with selectable channels.
Fixes#59718.
Fixes#50216.
Change-Id: I135a6656f5c48f0e5c43dc4d4bcbdb48ee5535d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/526117
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The time granularity on windows is large enough that setting even an
implausibly small timeout still gives ConnectEx enough time to succeed
before the timeout expires. That causes TestDialTimeout to sometimes
flake, because it expects to be able to provoke a timeout using some
nonzero duration.
This change takes a two-pronged approach to address the problem:
1. We can set a deadline on the FD more aggressively. (If the Context
has already expired, or the deadline is already known, we can go ahead
and set it on the fd without waiting for a background goroutine to get
around to it.)
2. We can reintroduce a test hook to ensure that Dial takes a
measurable amount of time before it completes, so that setting an
implausibly short deadline sets that deadline in the past instead of
the future.
Together, these reduce the flake rate on a windows-amd64-longtest
gomote from around 1-in-10 to less than 1-in-2000.
For #62377.
Change-Id: I03975c32f61fffa9f6f84efb3c474a01ac5a0d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/524936
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The LUCI builders seem to show that the failure mode in #62359 is not
specific to windows/arm64, but it occurs to me that we ought to be
able to eventually retry by making the timeout so short that the
remote end can't possibly respond in time (discounting the possibility
that the kernel itself might short-circuit the loopback address).
For #62377.
Updates #62359.
Updates #56876.
Change-Id: I1fb5fa4f2a5d2cfe35465f34248ed9a035f91f4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/524595
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Since we have only seen this failure mode on windows/arm64,
we do not skip on the Go project's windows/amd64 builders
so that we will be more likely to find out whether this failure mode
is specific to arm64.
Also simplify the ECONNRESET check, since I've remembered that the
error_*_test.go files exist.
Fixes#62359.
Updates #56876.
Change-Id: I17bd678486f3d3ec3363a45986a711f570b013d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/524455
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>
Run-TryBot: Bryan Mills <bcmills@google.com>
TestDialTimeout has historically been very flaky
(#11872, #13144, #22896, and now #56876),
apparently in part due to implementation details of the socktest
package it relies on.
In reviewing CL 467335, I noticed that TestDialTimeout is the last
remaining use of testHookDialChannel (added for #5349), and that that
hook no longer has any effect for Unix and Windows.
As an experiment, I tried removing both that hook and the call to
time.Sleep in the socktest filter, and to my surprise the test
continued to pass. That greatly undermined my confidence in the test,
since it appears that the “timeout” behavior it observes is caused by
the socktest filter injecting an error rather than anything in the net
package proper actually timing out.
To restore confidence in the test, I think it should be written
against only the public API of the net package, and should test the
publicly-documented behaviors. This change implements that approach.
Notably, when a timeout is set on a Dial call, that does not guarantee
that the listener will actually call Accept on the connection before
the timeout occurs: the kernel's network stack may preemptively accept
and buffer the connection on behalf of the listener. To avoid test
flakiness, the test must tolerate (and leave open) those spurious
connections: when the kernel has accepted enough of them, it will
start to block new connections until the buffered connections have
been accepted, and the expected timeout behavior will occur.
This also allows the test to run much more quickly and in parallel:
since we are relying on real timeouts instead of injected calls to
time.Sleep, we can set the timeouts to be much shorter and run
concurrently with other public-API tests without introducing races.
Fixes#56876.
Change-Id: I90dcb2ed70976e70857ca29c253ed760cb078a4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/524055
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Found by running
$ go run golang.org/x/tools/go/analysis/passes/nilness/cmd/nilness@latest std
No actual bugs--other than one panic(nil)--but a
few places where error nilness was unclear.
Change-Id: Ia916ba30f46f29c1bcf928cc62280169b922463a
Reviewed-on: https://go-review.googlesource.com/c/go/+/486675
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
Just rely on the testsuite timeout. If this hangs we will hopefully
get some real information.
Fixes#57475
Change-Id: I18dc5cae54ad5d2d8cc472056b8a3b4d5455c8b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/476356
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
After CL 470215 it should be safe to run this test on Plan 9.
Fixes#26945
Change-Id: I17880b696d2e91e6c4862fac05e6372f44e69b22
Reviewed-on: https://go-review.googlesource.com/c/go/+/472436
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Change-Id: Id4c3a140d9619796aee1ba3214f7d5fce040b4e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/435935
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This applies the net package CL 365334, CL 366176, CL 372215 to the os
package.
CL 365334:
These tests were checking for fairly narrow timing windows, but were
running in parallel and heavily dependent on timer and goroutine
scheduling. This change eliminates unnecessary goroutines, runs the
tests sequentially (dramatically shortening the timeouts to reduce the
penalty of doing so), and uses timestamp comparison instead of
background timers to hopefully gain some robustness from monotonic
timestamps.
Many of the other tests from this package would benefit from similar
simplifications, which we can apply if and when we notice flaky
failures or want to improve the latency of running the test.
CL 366176:
It appears that at least the OpenBSD kernel gets sloppier the longer
the timeout we give it, up to an observed overhead of around 25%.
Let's give it a little more than that (33%) in the comparison, and
also increase the growth curve to match the actual observed times
instead of exponential initial growth.
CL 372215:
Decrease the slop everywhere else, since NetBSD and OpenBSD seem to be
the only ones that miss by that much.
For #36108
For #50189Fixes#50725 (we hope)
Change-Id: I0854d27af67ca9fcf0f9d9e4ff67acff4c2effc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/415234
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The tester goroutine doesn't always gets a chance to run before the
timeout expires. Wait for the goroutine to start and set deadlines
before staring the timer.
Fixes#36796
Change-Id: Iffed6259de31340c3f66e34da473826a1d09fcde
Reviewed-on: https://go-review.googlesource.com/c/go/+/412858
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Decrease the slop everywhere else, since NetBSD and OpenBSD seem to be
the only ones that miss by that much.
For #50189
Updates #36108
Change-Id: I22ac39cc7c254e40358fcd933b5a6016629602c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/372215
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we set a timeout, we don't actually have a guarantee one how long
the OS will take to notice it. Moreover, if the test deadlocks
completely (for example, due to a deadline never taking effect), it
would be more useful to get a full goroutine dump instead of the current
"client stuck in Dial+Copy" failure message.
For #37883
For #41863
Change-Id: I9f712ef1c620f97a5ab69baac45deb71134b99bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/371994
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test cases for this test had listed specific errors, but the
specific error values were ignored in favor of just calling
isDeadlineExceeded.
Moreover, ENOBUFS errors (which can legitimately occur in the test if
the network interface also happens to be saturated when the timeout
occurs) were not handled at all.
Now the test relies only on the timeout: we iterate until we have seen
two of the expected timeout errors, and if we see ENOBUFS instead of
"deadline exceeded" we back off to give the queues time to drain.
Fixes#49930
Change-Id: I258a6d5c935d9635b02dffd79e197ba9caf83ac8
Reviewed-on: https://go-review.googlesource.com/c/go/+/370882
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Passing in an explicit testing.TB gives two benefits:
1. It allows the helper to fail the test itself, instead of returning
an error to the caller. A non-nil error invariably fails the
calling test, and none of these callers bother to add detail to the
error when logging it anyway so returning the error just added
noise to the test bodies.
2. It allows the helper to use t.Cleanup to perform any needed cleanup
tasks, which will be used in CL 370695 to clean up temp directories
used as namespaces for unix socket paths.
For #34611
Change-Id: I805e701687c12de2caca955649369294229c10b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/370696
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
It appears that at least the OpenBSD kernel gets sloppier the longer
the timeout we give it, up to an observed overhead of around 25%.
Let's give it a little more than that (33%) in the comparison, and
also increase the growth curve to match the actual observed times
instead of exponential initial growth.
Fixes#36108
Change-Id: Id3e54559b7c45b7c8bc0ca07dce74ca60e77e7ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/366176
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These tests were checking for fairly narrow timing windows, but were
running in parallel and heavily dependent on timer and goroutine
scheduling. This change eliminates unnecessary goroutines, runs the
tests sequentially (dramatically shortening the timeouts to reduce the
penalty of doing so), and uses timestamp comparison instead of
background timers to hopefully gain some robustness from monotonic
timestamps.
Many of the other tests from this package would benefit from similar
simplifications, which we can apply if and when we notice flaky
failures or want to improve the latency of running the test.
Fixes#36108
Change-Id: I17d8af7d2eefb1ec14fe0d9d891142a39599a562
Reviewed-on: https://go-review.googlesource.com/c/go/+/365334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This test seems only to be testing that Dial does not time out
immediately as a result of integer overflow; the precise time taken to
connect is immaterial. Replace naked loop with sub-tests.
Fixes#43069.
Change-Id: Ib5e38a1d8cd191b74c2bc7c26bef57b180e16f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/355390
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The old ioutil references are still valid, but update our code
to reflect best practices and get used to the new locations.
Code compiled with the bootstrap toolchain
(cmd/asm, cmd/dist, cmd/compile, debug/elf)
must remain Go 1.4-compatible and is excluded.
Also excluded vendored code.
For #41190.
Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/263142
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
If an I/O operation fails because a deadline was exceeded,
return os.ErrDeadlineExceeded. We used to return poll.ErrTimeout,
an internal error, and told users to check the Timeout method.
However, there are other errors with a Timeout method that returns true,
notably syscall.ETIMEDOUT which is returned for a keep-alive timeout.
Checking errors.Is(err, os.ErrDeadlineExceeded) should permit code
to reliably tell why it failed.
This change does not affect the handling of net.Dialer.Deadline,
nor does it change the handling of net.DialContext when the context
deadline is exceeded. Those cases continue to return an error
reported as "i/o timeout" for which Timeout is true, but that error
is not os.ErrDeadlineExceeded.
Fixes#31449
Change-Id: I0323f42e944324c6f2578f00c3ac90c24fe81177
Reviewed-on: https://go-review.googlesource.com/c/go/+/228645
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This removes all conditions and conditional code (that I could find)
that depended on darwin/arm.
Fixes#35439 (since that only happened on darwin/arm)
Fixes#37611.
Change-Id: Ia4c32a5a4368ed75231075832b0b5bfb1ad11986
Reviewed-on: https://go-review.googlesource.com/c/go/+/227198
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Before this CL adjustTimers left timers being moved in an inconsistent
state: status timerWaiting but not on a P. Simplify the code by
leaving the timers in timerMoving status until they are actually moved.
Other functions (deltimer, modtimer) will wait until the move is complete
before changing anything on the timer. This does leave timers in timerMoving
state for longer, but still not all that long.
Fixes#35367
Change-Id: I31851002fb4053bd6914139125b4c82a68bf6fb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/205418
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
You were a useful port and you've served your purpose.
Thanks for all the play.
A subsequent CL will remove amd64p32 (including assembly files and
toolchain bits) and remaining bits. The amd64p32 removal will be
separated into its own CL in case we want to support the Linux x32 ABI
in the future and want our old amd64p32 support as a starting point.
Updates #30439
Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/199499
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It is unclear whether the current definition of os.IsTimeout is
desirable or not. Drop ErrTimeout for now so we can consider adding it
(or some other error) in a future release with a corrected definition.
Fixes#33411
Change-Id: I8b880da7d22afc343a08339eb5f0efd1075ecafe
Reviewed-on: https://go-review.googlesource.com/c/go/+/188758
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Add Unwrap methods to types which wrap an underlying error:
"encodinc/csv".ParseError
"encoding/json".MarshalerError
"net/http".transportReadFromServerError
"net".OpError
"net".DNSConfigError
"net/url".Error
"os/exec".Error
"signal/internal/pty".PtyError
"text/template".ExecError
Add os.ErrTemporary. A case could be made for putting this error
value in package net, since no exported error types in package os
include a Temporary method. However, syscall errors returned from
the os package do include this method.
Add Is methods to error types with a Timeout or Temporary method,
making errors.Is(err, os.Err{Timeout,Temporary}) equivalent to
testing the corresponding method:
"context".DeadlineExceeded
"internal/poll".TimeoutError
"net".adrinfoErrno
"net".OpError
"net".DNSError
"net/http".httpError
"net/http".tlsHandshakeTimeoutError
"net/pipe".timeoutError
"net/url".Error
Updates #30322
Updates #29934
Change-Id: I409fb20c072ea39116ebfb8c7534d493483870dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/170037
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
This test is regularly failing on the plan9/386
builder running on GCE, but we haven't figured
out the issue yet.
Updates #26945.
Change-Id: I8cbe0df43c0757e7bc68e370311f4a28cd7b049b
Reviewed-on: https://go-review.googlesource.com/c/152721
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit adds the js/wasm architecture to the net package.
The net package is not supported by js/wasm, but a simple fake
networking is available so tests of other packages that require
basic TCP sockets can pass. The tests of the net package itself
are mostly disabled.
Updates #18892
Change-Id: Id287200c39f0a3e23d20ef17260ca15ccdcca032
Reviewed-on: https://go-review.googlesource.com/109995
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Calling UDPConn readers (Read, ReadFrom, ReadMsgUDP) to read part of
datagram returns error (in Windows), mentioning there is more data
available, and 0 as size of read data, even though part of data is
already read.
This fix makes UDPConn readers to return truncated payload size,
even there is error due more data available to read.
Fixes#14074
Updates #18056
Change-Id: Id7eec7f544dd759b2d970fa2561eef2937ec4662
Reviewed-on: https://go-review.googlesource.com/92475
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
This will make it possible to use the poller with the os package.
This is a lot of code movement but the behavior is intended to be
unchanged.
Update #6817.
Update #7903.
Update #15021.
Update #18507.
Change-Id: I1413685928017c32df5654ded73a2643820977ae
Reviewed-on: https://go-review.googlesource.com/36799
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It's too flaky and doing more harm than good.
Disable it until it can be made reliable.
Updates #17948
Updates #17927
Change-Id: Iaab7f09a4060da377fcd3ca2262527fef50c558d
Reviewed-on: https://go-review.googlesource.com/33330
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a followup to CL 33257.
It looks like active close operation at passive open side sometimes
takes a bit long time on Darwin.
Fixes#17948.
Change-Id: Ida17639c4e66a43e1be1f74fd0ef3baddde25092
Reviewed-on: https://go-review.googlesource.com/33258
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change makes use of synchronization primitive instead of
context-based canceling not to depend on defer execution scheduling.
Fixes#17927.
Change-Id: I5ca9287a48bb5cdda6845a7f12757f95175c5db8
Reviewed-on: https://go-review.googlesource.com/33257
Reviewed-by: Ian Lance Taylor <iant@golang.org>
forceCloseSockets is just designed as a kingston valve for TestMain
function and is not suitable to keep track of inflight sockets.
Fixes#15525.
Change-Id: Id967fe5b8da99bb08b699cc45e07bbc3dfc3ae3d
Reviewed-on: https://go-review.googlesource.com/23505
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Running
stress -p 1 go test -short std
on a heavily loaded machine causes net timeouts
every 15 or 20 runs.
Making these tests not run in parallel helps.
With this change, I haven’t seen a single failure
in over 100 runs.
Fixes#14986
Change-Id: Ibaa14869ce8d95b00266aee94d62d195927ede68
Reviewed-on: https://go-review.googlesource.com/21905
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Flaky tests are a distraction and cover up real problems.
File bugs instead and mark them as flaky.
This moves the net/http flaky test flagging mechanism to internal/testenv.
Updates #15156
Updates #15157
Updates #15158
Change-Id: I0e561cd2a09c0dec369cd4ed93bc5a2b40233dfe
Reviewed-on: https://go-review.googlesource.com/21614
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The existing implementation converts the deadline time to an int64,
but does not handle overflow. If the calculated deadline is negative
but the user specified deadline is in the future, then we can assume
the calculation overflowed, and set the deadline to math.MaxInt64.
Fixes#14431
Change-Id: I54dbb4f02bc7ffb9cae8cf62e4e967e9c6541ec6
Reviewed-on: https://go-review.googlesource.com/19758
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
This was supposed to be in CL 18205 but I submitted via the web
instead of from my computer, so it got lost.
May deflake some things.
Change-Id: I880fb74b5943b8a17f952a82639c60126701187a
Reviewed-on: https://go-review.googlesource.com/18259
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On darwin/arm, the test sometimes fails with:
Process 557 resuming
--- FAIL: TestWriteTimeoutFluctuation (1.64s)
timeout_test.go:706: Write took over 1s; expected 0.1s
FAIL
Process 557 exited with status = 1 (0x00000001)
go_darwin_arm_exec: timeout running tests
This change increaes timeout on iOS builders from 1s to 3s as a
temporarily fix.
Updates #10775.
Change-Id: Ifdaf99cf5b8582c1a636a0f7d5cc66bb276efd72
Reviewed-on: https://go-review.googlesource.com/9915
Reviewed-by: Minux Ma <minux@golang.org>
Bryan C. Mills
Oleksandr Redko
Alan Donovan
Johan Brandhorst-Satzkorn
Ian Lance Taylor
miller
cuiweixie
Dmitri Goutnik
Russ Cox
Tamir Duberstein
Austin Clements
Brad Fitzpatrick
Damien Neil
David du Colombier
Richard Musiol
Mansour Rahimi
Mikio Hara
Josh Bleecher Snyder
Prashant Varanasi