Change-Id: I7dfae0fc91c2d70873ec7ec920be7c0a4888153a
Reviewed-on: https://go-review.googlesource.com/c/go/+/390175
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Advertise to DNS resolvers that we are willing and able to accept up
to 1232 bytes in a DNS packet. The value 1232 was chosen based on
https://dnsflagday.net/2020/.
For #6464
For #21160
For #44135
For #51127Fixes#51153
Change-Id: If9182d5210bfe047cf0a4d46163effc6812ab677
Reviewed-on: https://go-review.googlesource.com/c/go/+/386016
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There is code in the wild that copies the Buffers slice,
but not the contents.
Let's document explicitly that it is not safe to do so.
Updates #45163
Change-Id: Id45e27b93037d4e9f2bfde2558e7869983b60bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/387434
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The existing value of 512 bytes as is specified by RFC 1035.
However, the WSL resolver reportedly sends larger packets without
setting the truncation bit, which breaks using the Go resolver.
For 1.18 and backports, just increase the accepted packet size.
This is what GNU glibc does (they use 65536 bytes).
For 1.19 we plan to use EDNS to set the accepted packet size.
That will give us more time to test whether that causes any problems.
No test because I'm not sure how to write one and it wouldn't really
be useful anyhow.
Fixes#6464Fixes#21160Fixes#44135Fixes#51127
For #51153
Change-Id: I0243f274a06e010ebb714e138a65386086aecf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/386015
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts https://go.dev/cl/385035. For 1.18 we will use a simple
change to increase the accepted DNS packet size, to handle what appear
to be broken resolvers that don't honor the 512 byte limit. For 1.19
we will restore CL 385035 to make a proper EDNS request, so that it
has more testing time before it goes out in a release.
For #6464
For #21160
For #44135
For #51127
For #51153
Change-Id: Ie4a0eb85ca0a6a73bee5cd4cfc6b7d2a15ef259f
Reviewed-on: https://go-review.googlesource.com/c/go/+/386014
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Previously, TestNotTemporaryRead issued the Read on the Accept side of
the connection, and Closed the Dial side. It appears that on some
platforms, Dial may return before the connection has been Accepted,
and if that connection is immediately closed with no bytes written and
SO_LINGER set to 0, the connection may no longer even exist by the
time Accept returns, causing Accept to block indefinitely until the
Listener is closed.
If we were to just swap the directions, we would have an analogous
problem: Accept could accept the connection and close it before the
client even finishes dialing, causing Dial (instead of Read) to return
the ECONNRESET error.
Here, we take a middle path: we Accept and Dial the connection
concurrently, but wait until both the Accept and the Dial have
returned (indicating that the connection is completely established and
won't vanish from the accept queue) before resetting the connection.
Fixes#29685
Updates #25289
Change-Id: Ida06f70f7205fffcdafa3df78bd56184e6cec760
Reviewed-on: https://go-review.googlesource.com/c/go/+/385314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When we receive an error writing the first byte of a request to a
reused connection, we retry the request on a new connection. Remove
a flaky path which could cause the request to not be retried if
persistConn.roundTrip reads the error caused by closing the connection
before it reads the write error that caused the connection to be
closed.
Fixes#30938.
Change-Id: Iafd99e3239cd9dba4a4c9ddd950a877ca9815e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/379554
Trust: Bryan Mills <bcmills@google.com>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We used to only accept up to 512 bytes in a DNS packet, per RFC 1035.
Increase the size we accept to 1232 bytes, per https://dnsflagday.net/2020/,
and advertise that larger limit in a EDNS(0) OPT record.
Fixes#6464Fixes#21160Fixes#44135Fixes#51127
Change-Id: I496a294e9a8015de4161cbc1825b0dc5b4e9f5d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/385035
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If the actual DNS lookup in LookupIPAddr completes quickly enough,
it may succeed even if the passed-in Context is already canceled.
That would (rarely) cause TestLookupContextCancel to fail due to an
unexpectedly-nil error.
This change uses the existing testHookLookupIP hook to delay the
cancellation until the lookup has started (to try to provoke the code
path for which the test was added), and then block the lookup result
until LookupIPAddr has noticed it.
Fixes#51084
Updates #22724
Change-Id: I331ac61a652ac88f6d4c85bf62466237b76d53ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/384237
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Looking at history, it appears to never have worked as documented.
Fixes#48759
Change-Id: I066307c28e3ed1875c1c4049bade62e2818dd400
Reviewed-on: https://go-review.googlesource.com/c/go/+/383998
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Looking at the condition actually exercised by the test it seems
unnecessary: assuming that the Write succeeds (checked earlier in the
test), the Read must have a nonzero number of bytes available to read
immediately. (That is not the case in TestUDPZeroByteBuffer, from
which this test appears to have been derived.)
Fixes#50870
Change-Id: Ia6040a2d5dc320f0b86ec9d6f6b91dc72e8f3b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/382537
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This extends the skip added in CL 375635 to the "_Headers" variant of
the test, since we have observed similar failures in that variant on
the builders.
For #43120
Change-Id: Ib1c97fbb776b576271629272f3194da77913a941
Reviewed-on: https://go-review.googlesource.com/c/go/+/379156
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When an http.FileServer is given a path like file1/file2 where file1
exists but file2 does not, the proper HTTP status should be
NotFound. Some OSes return a "not a directory" error instead, so this
must be mapped to NotFound.
That mapping was already being done for the Dir FileSystem
implementation, as discussed in #18984. But it wasn't for the
FS implementation.
This CL does the same mapping for FS, by generalizing the function
that did it for Dir.
Fixes#49552
Change-Id: I61d6aa8ef101158e9674707d44e653f5dedbd040
Reviewed-on: https://go-review.googlesource.com/c/go/+/376874
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Upgrade the test certificate from RSA 1024 (not FIPS-approved)
to RSA 2048 (FIPS-approved), allowing tests to pass when
the dev.boringcrypto branch FIPS-only mode is enabled.
Fixes#48674.
Change-Id: I613d2f8d0207bf3683fd0df256bf0167604996c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353869
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The arbitrary sleep in this test is empirically not always long enough
on slower builders. However, we know the exact number of connections
that should be dialed: we can wait on that number in the dial hook
instead.
Fixes#34495
Change-Id: I538244ceb75a80271a724304b993309482bd5b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/375694
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>
These tests are empirically flaky on the windows/arm and windows/arm64
builders, with a consistent (but rare) failure mode.
This change skips the test if that particular failure mode is
encountered on those platforms; the skip can be removed if and when
someone has the time to pin down the root cause.
For #43120
Change-Id: Ie3a9a06bf47e3a907c7b07441acc1494a4631135
Reviewed-on: https://go-review.googlesource.com/c/go/+/375635
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The code looks like it was already trying to avoid this but missed a
spot.
Fixes#50271.
Change-Id: I450adac3f618b9535b61a28e6a160eacc351d47c
Reviewed-on: https://go-review.googlesource.com/c/go/+/373075
Trust: Jason Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The links to this example were using an underscore separator
instead of a hyphen, and incorrect casing.
Fixes#50279
Change-Id: I35d76a8a78cd708b7505ff1a70f7dacddaf43efd
Reviewed-on: https://go-review.googlesource.com/c/go/+/373514
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This is a pretty straight port of the fuzz test at https://github.com/inetaf/netaddr.
The MarshalText methods of netip.Addr and net.IP, the Is* methods of netip.Addr
and net.IP and the MarshalText and String methods of netip.Addr are also
checked to ensure that they behave the same way.
Fixes#49367
Change-Id: I44abb01f2a7af45f39597992a1fc7ff0305728fa
GitHub-Last-Rev: c2323b0ae1
GitHub-Pull-Request: golang/go#50108
Reviewed-on: https://go-review.googlesource.com/c/go/+/371055
Trust: Matt Layher <mdlayher@gmail.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
The "someTimeout" constant in the net test is “just to test that
net.Conn implementations don't explode when their SetFooDeadline
methods are called”. It was set to 10 seconds, which is short enough
that it could actually matter on some platforms.
Since the point of the constant is just to make sure methods don't
explode, we should set it to be at least a couple of orders of
magnitude longer than the test: then it is guaranteed not to have any
unintended side-effects.
Fixes#50227
Change-Id: If97ae7bef5e7f16b336d09ccc37f5ea2ea7e70b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/372796
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It is observed to be flaky on the only openbsd/arm builder.
Skipping on that platform until someone can investigate.
For #50218
Change-Id: Id3a6dc12b93b3cec67870d8d81bd608c4589c952
Reviewed-on: https://go-review.googlesource.com/c/go/+/372794
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.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>
h2_bundle.go is automatically generated from x/net/http2. Any
formatting changes within that file need to be first made upstream.
This brings the contents of h2_bundle.go back in line with the
upstream generator, fixing the cmd/internal/moddeps test that is
currently failing on the longtest builders.
For #49884
Change-Id: I5757240b77e250e0026b8a52a0e867e1578ec2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/371297
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.
Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.
A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.
Fixes#49884.
Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09
Reviewed-on: https://go-review.googlesource.com/c/go/+/368254
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@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>
This change applies the same transformation as in CL 366774,
but to the net package.
testUnixAddr was using os.CreateTemp to obtain a unique socket path,
but then calling os.Remove on that path immediately. Since the
existence of the file is what guarantees its uniqueness, that could
occasionally result in testUnixAddr returning the same path for two
calls, causing the tests using those paths to fail — especially if
they are the same test or are run in parallel.
Instead, we now create a unique, short temp directory for each call,
and use a path within that directory for the socket address.
For #34611
Change-Id: I8e13b606abce2479a0305f7aeecf5d54c449a032
Reviewed-on: https://go-review.googlesource.com/c/go/+/370694
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>
The exact error isn't actually relevant to the test,
and may depend on whether the Go or cgo resolver is used.
Also run the test in parallel, because it spends most of its time
sleeping in between lookups.
Fixes#38767Fixes#43140
Change-Id: I2d64ffddf2eb114a69ed3242daa9a9e4a5679f67
Reviewed-on: https://go-review.googlesource.com/c/go/+/369037
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestUnixAndUnixpacketServer deferred a call to os.Remove on the local
address of a dialed unix domain socket, in an attempt to remove the
socket from the server. However, that call appears to be neither
necessary nor correct.
In this test, the file that needs to be unlinked is the one attached
to the listener — but the listener's Close method already does that
(see the Unlink call in (*UnixListener).close), so there is no need
for the test itself to do the same.
Moreover, the local address is not something that is sensible to
delete — on Linux, it is empirically always the literal string "@" —
and the Addr returned by c.LocalAddr is not reliably non-nil on all
platforms (see #34611).
Since we don't need to do anything with the local address, we shouldn't.
At best, this is a benign Remove of a file that doesn't exist anyway;
at worst, it is a nil-panic.
Fixes#34611
Change-Id: Ie072b3388d884d60e819d1df210fa7d3e2eed124
Reviewed-on: https://go-review.googlesource.com/c/go/+/370695
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestListenerClose had been asserting that a Dial to the newly-closed
address always fails, on the assumption that the listener's address
and port would not be reused by some other listener that could then
accept the connection.
As far as I can tell, that assumption is not valid: the Dial after
Close may well connect to a Listener opened for some other test, or
even one opened by a completely different process running concurrently
on the same machine.
Fixes#38700
Change-Id: I925ed1b2ccb556135a2c5be0240d1789ed27d5fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/370666
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Weird, but don't drop the zone when stringifying.
Fixes#50111
Change-Id: I5fbccdfedcdc77a77ee6bafc8d82b8ec8ec7220c
Reviewed-on: https://go-review.googlesource.com/c/go/+/371094
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Trust: Matt Layher <mdlayher@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
The failure mode in #34264 appears to match
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210726.
That bug was supposed to have been fixed in FreeBSD 12, but we're
still observing failures specifically for the 6-to-4 case on FreeBSD
12.2. It is not clear to me whether FreeBSD 13.0 is also affected.
For #34264
Change-Id: Iba7c7fc57676ae628b13c0b8fe43ddf2251c3637
Reviewed-on: https://go-review.googlesource.com/c/go/+/369157
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test seems like it needs attention from a TLS and/or FreeBSD
expert. In the meantime, it needs to stop causing noise on the build
dashboard.
For #19229
Change-Id: If7e9e3533ae7cb29006a670c3e9df90512dcf9f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/370137
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 366536
Reason for revert: may have caused #50033 due to an invalid or partially-populated *TCPAddr
Fixes#50033
Change-Id: Ia29ca4116503dba65d56e89caa46ba1c848d421a
Reviewed-on: https://go-review.googlesource.com/c/go/+/369982
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test fails with "timeout" once per couple of months.
It may be that the arbitrary timeout is too short,
or it may be that the test is detecting a real bug
(perhaps a deadlock) and reporting it without sufficient
information to debug.
Either way, the arbitrary timeout is doing only harm:
either it is too short, or it is preventing us from getting
a useful goroutine dump when the test inevitably times out.
Fixes#35498 (hopefully).
Change-Id: Ic6bbb1ef8df2c111b9888ba9903f58633e7cb95d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369854
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
'man getsockname' lists a number of possible failure modes, including
ENOBUFS (for resource exhaustion) and EBADF (which we could possibly
see in the event of a bug or race condition elsewhere in the program).
If getsockname fails for an explicit user-provided local address, the
user is probably not expecting LocalAddr on the returned net.Conn to
return nil. This may or may not fix#34611, but should at least help
us diagnose it more clearly.
While we're add it, also add more nil-checking logic in the test based
on the stack traces posted to
https://golang.org/issue/34611#issuecomment-975923748.
For #34611
Change-Id: Iba870b96787811e4b9959b74ef648afce9316602
Reviewed-on: https://go-review.googlesource.com/c/go/+/366536
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>
When TestPacketConn was added (in CL 6501057) it included arbitrary
100ms deadlines. Those deadlines were arbitrarily increased to 500ms
in CL 4922.
If the test is actually provoking a deadlock, allowing it to deadlock
will give us a more useful goroutine dump. Otherwise, the deadlines
don't seem all that useful — they appear to increase code coverage,
but have no effect on the test in the typical case, and can only
cause flakes on particularly-slow machines.
For #43627
Change-Id: I83de5217c54c743b83adddf51d4f6f2bd5b91732
Reviewed-on: https://go-review.googlesource.com/c/go/+/368215
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>
Apparently, on the iOS builder sendfile causes a SIGSYS signal
(instead of returning ENOSYS). Disabling it for now so we can
make progress on iOS. We can revisit if sendfile is actually
broken on iOS and whether it is beneficial.
Updates #49616.
Change-Id: I3883fad0ce35e3f0aa352301eb499a1afa0225a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/368054
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Changkun Ou <mail@changkun.de>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This test occasionally hangs on the darwin-arm64-11_0-toothrot
builder. When it does, it fails with the unhelpful error message
"timeout" instead of a useful goroutine dump.
This change eliminates the use of an arbitrary timeout channel, so
that if (and probably when) the test hangs again we will get more
useful logs to diagnose the root cause.
For #49860
Change-Id: I23f6f1c81209f0b2dbe565e1dfb26b1b2eff0187
Reviewed-on: https://go-review.googlesource.com/c/go/+/367615
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This brings in a fix for OpenBSD that lets it correctly gather network
interface information.
For #42064
Change-Id: Ib88fd2f494bb2ee86fd2725d8375b2df1404c4ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/366756
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <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>
For #34611
Change-Id: I31894d58498b2c290ecceccfc004bc817f8969c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/366114
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
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>
Dan Kortschak
Ian Lance Taylor
Martin Sucha
Bryan C. Mills
Damien Neil
Sean Liao
Jonathan Amsterdam
Jason A. Donenfeld
Reilly Watson
Andrew LeFevre
Russ Cox
Matt Layher
Brad Fitzpatrick
Filippo Valsorda
Cherry Mui