This makes testenv.RunWithTimeout first attempt to SIGQUIT the
subprocess to get a useful Go traceback, but if that doesn't work, it
sends a SIGKILL instead to make sure we tear down the subprocess. This
is potentially important for non-Go subprocesses.
For #37405.
Change-Id: I9e7e118dc5769ec3f45288a71658733bff30c9cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/370702
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This lifts the logic to run a subcommand with a timeout in a test from
the runtime's runTestProg into testenv. The implementation is
unchanged in this CL. We'll improve it in a future CL.
Currently, tests that run subcommands usually just timeout with no
useful output if the subcommand runs for too long. This is a step
toward improving this.
For #37405.
Change-Id: I2298770db516e216379c4c438e05d23cbbdda51d
Reviewed-on: https://go-review.googlesource.com/c/go/+/370701
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
cmd/vet has several precision improvements for the checkers copylock, printf, sortslice, testinggoroutine, and tests. Adds a high level mention in the release notes and an example of string constant concatenation.
Updates #47694
Change-Id: I7a342a57ca3fd9e2f3e8ec99f7b647269798317f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370734
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Gopher Robot <gobot@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>
When exporting the "any" empty interface type for unified IR, write it
out as a reference to the "any" alias, rather than to the underlying
empty interface. This matches how "byte" and "rune" are handled.
Verified to fix the issue demonstrated in CL 369975.
Change-Id: Ic2844b0acc3b17c20b3a40aaf262f62ec653eb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/370374
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The 'Does not match' type error shoud be reported where
the function is called, not where the function is declared.
And fix the todo by gri of issue45985
Fixes#45985Fixes#49800
Change-Id: I15aac44dd44f2a57c485a1c273fcd79db912c389
Reviewed-on: https://go-review.googlesource.com/c/go/+/362634
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The "-2008" builders are the only ones on which the failure has
been observed, so I suspect that it is due to a platform bug fixed in a
subsequent release.
Since no one has added a workaround since #19564 was filed over four
years ago, I'm assuming that no workaround is planned for this issue.
Let's add a skip for the known failure mode and call it at that.
Fixes#19564
Change-Id: Iefc22d1cc78bfdc79c845eb60cac22e26caf388c
Reviewed-on: https://go-review.googlesource.com/c/go/+/370377
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Generally speaking Go functions make no guarantees
about what has happened to result parameters on error,
and Pipe is no exception: callers should avoid looking at
p if Pipe returns an error.
However, we had a bug in which ForkExec was using the
content of p after a failed Pipe, and others may too.
As a robustness fix, make Pipe avoid writing to p on failure.
Updates #50057
Change-Id: Ie8955025dbd20702fabadc9bbe1d1a5ac0f36305
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291271
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370577
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Pipe (and therefore forkLockPipe) does not make any guarantees
about the state of p after a failed Pipe(p). Avoid that assumption
and the too-clever goto, so that we don't accidentally Close a real fd
if the failed pipe leaves p[0] or p[1] set >= 0.
Fixes#50057
Fixes CVE-2021-44717
Change-Id: Iff8e19a6efbba0c73cc8b13ecfae381c87600bb4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291270
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370576
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Also update some other go/types release notes to use the present tense.
Updates #47694
Change-Id: I654371c065e76fd5d22679d0d3c1a81bc3d1e513
Reviewed-on: https://go-review.googlesource.com/c/go/+/370235
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TestLabelSystemstack needs to collect samples within runtime.systemstack
to complete the test.
The current approach uses fmt.Fprintf, which gets into systemstack
through the allocator and GC, but also does lots of other work. In my
measurements, approximately 2% of samples contain runtime.systemstack.
The new approach uses debug.SetGCPercent, which uses systemstack for
most of its work, including contention on mheap_.lock, which extends
usage even more. In my measurements, approximately 99% of samples
contain runtime.systemstack.
Fixes#50050
Change-Id: I59e5bb756341b716a12e13d2e3fe0adadd7fe956
Reviewed-on: https://go-review.googlesource.com/c/go/+/370375
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently run one 'go list' invocation per GOMAXPROC. Since the go
command uses memory and has its own internal parallelism, that's
unlikely to be an efficient use of resources. Run half as many. I
suspect that's still too many but this should fix our OOMs.
For #49957.
Change-Id: Id06b6e0f0d96387a2a050e400f38bde6ba71aa60
Reviewed-on: https://go-review.googlesource.com/c/go/+/370376
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Note when a statement mark was not consumed during Prog
generation, and try to use it on a subsequent opcode so
that the statement marker will not be lost.
And a test.
Fixes#49628.
Change-Id: I03f7782a9809cc4a0a5870df92b3e182cf124554
Reviewed-on: https://go-review.googlesource.com/c/go/+/366694
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Augmented some of the typeswitch*.go tests so that some instantiations
have duplicate cases, in order to ensure we're testing that.
Spacing changes in the tests are due to gofmt.
Change-Id: I5d3678813505c520c544281d4ac8a62ce7e236ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/370155
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
golang.org/cl/365234 incorrectly had pruningForGoVersion always return
workspace pruning instead of just returning workspace pruning at the top
level, which broke the proper determination of pruning for dependency
packages. Fix that code, and also fix a hang that resulted because the
module loading code keeps loading dependencies until it reaches a pruned
module or an unpruned module it already saw, so it could get stuck in a
cycle.
Change-Id: I8911f7d83aaee5870c43ef0355abbd439f15d4f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/366775
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a clean port of CL 369434 to types2.
Change-Id: I3f9f80757bfbefb7b0417eef9e7b7c74c4c100b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/369474
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Our calculation of initOrder builds the dependency graph and then
removes function nodes approximately at random. While profiling, I
noticed that this latter step introduces a superlinear algorithm into
our type checking pass, which can dominate type checking for large
packages such as runtime.
It is hard to analyze this rigorously, but to give an idea of how such a
non-linearity could arise, suppose the following assumptions hold:
- Every function makes D calls at random to other functions in the
package, for some fixed constant D.
- The number of functions is proportional to N, the size of the package.
Under these simplified assumptions, the cost of removing an arbitrary
function F is P*D, where P is the expected number of functions calling
F. P has a Poisson distribution with mean D.
Now consider the fact that when removing a function F in position i, we
recursively pay the cost of copying F's predecessors and successors for
each node in the remaining unremoved subgraph of functions containing F.
With our assumptions, the size of this subgraph is proportional to
(N-i), the number of remaining functions to remove.
Therefore, the total cost of removing functions is proportional to
P*D*Σᴺ(N-i)
which is proportional to N².
However, if we remove functions in ascending order of cost, we can
partition by the number of predecessors, and the total cost of removing
functions is proportional to
N*D*Σ(PMF(X))
where PMF is the probability mass function of P. In other words cost is
proportional to N.
Assuming the above analysis is correct, it is still the case that the
initial assumptions are naive. Many large packages are more accurately
characterized as combinations of many smaller packages. Nevertheless, it
is intuitively clear that removing expensive nodes last should be
cheaper.
Therefore, we sort by cost first before removing nodes in
dependencyGraph.
We also move deletes to the outer loop, to avoid redundant deletes. By
inspection, this avoids a bug where n may not have been removed from its
successors if n had no predecessors.
name old time/op new time/op delta
Check/runtime/funcbodies/noinfo-8 568ms ±25% 82ms ± 1% -85.53% (p=0.000 n=8+10)
name old lines/s new lines/s delta
Check/runtime/funcbodies/noinfo-8 93.1k ±56% 705.1k ± 1% +657.63% (p=0.000 n=10+10)
Updates #49856
Change-Id: Id2e70d67401af19205e1e0b9947baa16dd6506f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369434
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Preparation for #44505, but safe for Go 1.18.
Also fixes the default build on Macs, at least for
people who have a $HOME/go1.17 or have run
go install golang.org/dl/go1.17@latest
go1.17 download
Replay of CL 369914 after revert in CL 370138.
Only change is adding 'export GOROOT_BOOTSTRAP' in make.bash.
Change-Id: I8ced4e87a9dc0f05cc49095578b401ae6212ac85
Reviewed-on: https://go-review.googlesource.com/c/go/+/370274
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the test's main goroutine receives a SIGPROF while creating the
C-owned thread for the test, that sample will appear in the resulting
profile. The root end of that stack will show a set of Go functions. The
leaf end will be the C functions returned by the SetCgoTraceback
handler, which will confuse the test runner.
Add a label to the main goroutine while it calls in to C, so all profile
samples that triggered the SetCgoTraceback handler are either correct,
or can easily be excluded from the test's analysis. (The labels will not
apply to the resulting C-owned thread, which does not use goroutines.)
Fixes#43174
Change-Id: Ica3100ca0f191dcf91b30b0084e8541c5a25689f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370135
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@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>
As a side effect of the changes in cmd/go/internal/work in CL 369977,
binaries built in GOPATH mode now include rudimentary build metadata
for at least the package path and compiler in use.
That seems like a strict improvement, but the test needs to be updated
to reflect the newly-available metadata.
Change-Id: I657c785e3e9992ed594c9524409f2d076f9eb376
Reviewed-on: https://go-review.googlesource.com/c/go/+/370234
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
cd src/cmd
go get golang.org/x/tools@fd2bfb7
go mod tidy
go mod vendor
Brings in fixes to cmd/vet for 'any' changes.
Change-Id: I70a48d451bd99f5d82f91fd079fbdd1b4bac2520
Reviewed-on: https://go-review.googlesource.com/c/go/+/370136
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
That is replaced by `go work edit`.
Change-Id: I39996c7bea0182a18edf6a1f70b6616c74099a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/370139
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
This reverts https://golang.org/cl/369914.
Reason for revert: Breaking previously working toolchain builds.
For #44505.
Change-Id: I09ae20e50109a600d036358118077d27669df39c
Reviewed-on: https://go-review.googlesource.com/c/go/+/370138
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With https://golang.org/issue/50007 resolved, there are no known issues
with pprof labels remaining. Thus, the 10% allowed error in
TestLabelSystemstack should not be required.
Drop it in favor of an explicit assertion that all samples containing
labelHog are properly labeled.
This is no flaky in my local testing. It is possible that other bugs
will appear at larger testing scale, in which case this CL will be
reverted, but then at least we will be aware of additional failure
modes.
For #50007.
Change-Id: I1ef530c303bd9a01af649b8b08d4b35505e8aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/369744
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
profBuf.write uses an index in b.tags for each entry, even if that entry
has no tag (that slice entry just remains 0). profBuf.read similarly
returns a tags slice with exactly as many entries as there are records
in data.
profileBuilder.addCPUData iterates through the tags in lockstep with the
data records. Except in the special case of the first record, where it
forgets to increment tags. Thus the first read of profiling data has all
tags off-by-one.
To help avoid regressions, addCPUData is changed to assert that tags
contains exactly the correct number of tags.
For #50007.
Change-Id: I5f32f93003297be8d6e33ad472c185d924a63256
Reviewed-on: https://go-review.googlesource.com/c/go/+/369741
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Deal with case where a certain instantiation of a generic
function/method leads to an unsatisfiable type assertion or type case.
In that case, the compiler was causing a fatal error while trying to
create an impossible itab for the dictionary. To deal with that case,
allow ITabLsym() to create a dummy itab even when the concrete type
doesn't implement the interface. This dummy itab is analogous to the
"negative" itabs created on-the-fly by the runtime.
We will use the dummy itab in type asserts and type switches in
instantiations that use that dictionary entry. Since the dummy itab can
never be used for any real value at runtime (since the concrete type
doesn't implement the interface), there will always be a failure for the
corresponding type assertion or a non-match for the corresponding
type-switch case.
Fixes#50002
Change-Id: I1df05b1019533e1fc93dd7ab29f331a74fab9202
Reviewed-on: https://go-review.googlesource.com/c/go/+/369894
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, if an unrecoverable error occurred during
minimization, then the input that caused the failure
could not be retrieved by the coordinator. This was fine
if minimizing a crash, since the coordinator could simply
report the original error, and ignore the new one.
However, if an error occurred while minimizing an
interesting input, then we may lose an important error
that would be better to report.
This changes is a pretty major refactor of the minimization
logic in order to support this. It removes minimization
support of all types except []byte and string. There isn't
compelling evidence that minimizing types like int or float64
are actually beneficial, so removing this seems fine.
With this change, the coordinator requests that the worker
minimize a single value at a time. The worker updates shared
memory directly during minimzation, writing the *unmarshaled*
bytes to the shared memory region. If a nonrecoverable error occurs
during minimization, then the coordinator can get the
unmarshaled value out of shared memory for that type being
minimized.
Fixes#48731
Change-Id: I4d1d449c411129b3c83b148e666bc70f09e95828
Reviewed-on: https://go-review.googlesource.com/c/go/+/367848
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reading the version information to date has required evaluating
two pointers to strings (which themselves contain pointers to data),
which means applying relocations, which can be very system-dependent.
To simplify the lookup, inline the string data into the build info blob.
This makes go version work on binaries built with external linking
on darwin/arm64.
Also test that at least the very basics work on a trivial binary,
even in short mode.
Change-Id: I463088c19e837ae0ce57e1278c7b72e74a80b2c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369977
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Preparation for #44505, but safe for Go 1.18.
Also fixes the default build on Macs, at least for
people who have a $HOME/go1.17 or have run
go install golang.org/dl/go1.17@latest
go1.17 download
Change-Id: I822f93e75498620fad87db2436376148c42f6bff
Reviewed-on: https://go-review.googlesource.com/c/go/+/369914
Trust: Russ Cox <rsc@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>
Fixes for #49680, #49695, #45867, and #49370 all assumed that
SetGCPercent(-1) doesn't block until the GC's mark phase is done, but
it actually does. The cause of 3 of those 4 failures comes from the fact
that at the beginning of the sweep phase, the GC does try to preempt
every P once, and this may run concurrently with test code. In the
fourth case, the issue was likely that only *one* of the debug_test.go
tests was missing a call to SetGCPercent(-1). Just to be safe, leave a
TODO there for now to remove the extraneous runtime.GC calls, but leave
the calls in.
Updates #49680, #49695, #45867, and #49370.
Change-Id: Ibf4e64addfba18312526968bcf40f1f5d54eb3f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/369815
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 358539 revised the build-stamp format, and updated the git and hg
tests to match. However, the fossil and bzr tests were missed, and
were not caught on the builders due to the fact that none of the
builder images have the necessary VCS tools installed.
Updates #48802
Updates #49168
Change-Id: I6b9fd0e19b81cb539864c94ab0860f74e7be6748
Reviewed-on: https://go-review.googlesource.com/c/go/+/369743
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
'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>
The test was skipped because with the old gold linker on the
builder it fails with an internal error in gold. The builders now
have gold 2.31 and the test passes. Enable it.
Fixes#17138.
Change-Id: Ia0054030dd12f1d003c7420bf7ed8b112715baa9
Reviewed-on: https://go-review.googlesource.com/c/go/+/369814
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
