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>
SetGCPercent(-1) is called by several tests in debug_test.go (followed
by a call to runtime.GC) due to #49370. However, startDebugCallWorker
already actually has this, just without the runtime.GC call (allowing an
in-progress GC to still mess up the test).
This CL consolidates SetGCPercent into startDebugDebugCallWorker where
applicable.
Change-Id: Ifa12d6a911f1506e252d3ddf03004cf2ab3f4ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369751
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Though this was a problem for Go 1.17,
it appears not to be a problem on tip.
This reverts change made in CL 321349.
For #46239.
Change-Id: Ie4d6649fbabce3bb2c1cf04d97760ba6ceadaca5
Reviewed-on: https://go-review.googlesource.com/c/go/+/369752
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
These tests disable GC because of the potential for a deadlock, but
don't consider that a GC could be in progress due to other tests. The
likelihood of this case was increased when the minimum heap size was
lowered during the Go 1.18 cycle. The issue was then mitigated by
CL 368137 but in theory is always a problem.
This change is intended specifically for #45867, but I just walked over
a whole bunch of other tests that don't take this precaution where it
seems like it could be relevant (some tests it's not, like the
UserForcedGC test, or testprogs where no other code has run before it).
Fixes#45867.
Change-Id: I6a1b4ae73e05cab5a0b2d2cce14126bd13be0ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/369747
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
startServer was invoking os.Remove on the temporary file for a unix
socket after creating it. Since the files were created in the global
temp directory, that could cause two tests to arrive at colliding
names.
(Noticed while looking into the failure at
https://storage.googleapis.com/go-build-log/af2c83b1/solaris-amd64-oraclerel_3e01fda8.log,
but I would be surprised if this solves that failure.)
This change uses unique temporary directories, and attempts to keep
name lengths minimal to avoid accidentally running into socket-name
length limitations.
Updates #34611
Change-Id: I21743f245e5c14645e03f09795013e058b984471
Reviewed-on: https://go-review.googlesource.com/c/go/+/366774
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 CL reorders the bullet points in the generics section to more
closely match what I think users will consider most important. I put
the ~ token before the mention of ~T in interfaces to avoid a forward
reference, though I wonder if we actually want to spent a couple more
sentences saying what union and ~T types are, since most people are
going to care about that a lot more than they care about the low-level
detail that there's a new token.
For #47694.
Change-Id: Ib84f096ef6346a711801268ce362b64fa423d3f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/369734
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To prevent interleaving of output when 'go build' compiles several
packages in parallel, the output mutex in the Builder struct must
be locked around any calls to Builder.Print which could generate
arbitrary amounts of text (ie more than is guaranteed to be written
atomically to a pipe).
Fixes#49987
For #49338
Change-Id: I7947df57667deeff3f03f231824298d823f8a943
Reviewed-on: https://go-review.googlesource.com/c/go/+/369018
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Russ Cox <rsc@golang.org>
In iOS <14, the address space is strictly limited to 8 GiB, or 33 bits.
As a result, the page allocator also assumes all heap memory lives in
this region. This is especially necessary because the page allocator has
a PROT_NONE mapping proportional to the size of the usable address
space, so this keeps that mapping very small.
However starting with iOS 14, this restriction is relaxed, and mmap may
start returning addresses outside of the <14 range. Today this means
that in iOS 14 and later, users experience an error in the page
allocator when a heap arena is mapped outside of the old range.
This change increases the ios/arm64 heapAddrBits to 40 while
simultaneously making ios/arm64 use the 64-bit pagealloc implementation
(with reservations and incremental mapping) to accommodate both iOS
versions <14 and 14+.
Once iOS <14 is deprecated, we can remove these exceptions and treat
ios/arm64 like any other arm64 platform.
This change also makes the BaseChunkIdx expression a little bit easier
to read, while we're here.
Fixes#46860.
Change-Id: I13865f799777739109585f14f1cc49d6d57e096b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344401
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This CL updates "go help doc" docs so they reflect the following
changes:
- CL 59413 modified "go doc", so the behavior of the two-args case is
consistent with the one-arg one.
- CL 141397 removed godoc's command-line interface in favor of "go doc".
Fixes#49830.
Change-Id: I0923634291d34ae663fe2944d69757462b814919
Reviewed-on: https://go-review.googlesource.com/c/go/+/367497
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Russ Cox <rsc@golang.org>
NewTypeList was not part of the go/types API proposal, and was left in
by accident. It also shouldn't be necessary, so remove it.
Updates #47916
Change-Id: I4db3ccf036ccfb708ecf2c176ea4921fe68089a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369475
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>
Update the vendored x/sys to pick up CL 368994, which remove the
declaration of function darwinSupportsAVX512 in cpu/cpu_gc_x86.go.
The following commands were used:
go get -d golang.org/x/sys@97ca703d548df069cb02aacea9efc3093ffdc3c4
go mod tidy
go mod vendor
Fixes#49942
Change-Id: I05162a051f572bf8599be198a6033384b7d19445
Reviewed-on: https://go-review.googlesource.com/c/go/+/369454
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The type was changed in https://golang.org/cl/3991043 but the comment
wasn't updated.
Change-Id: I7ba3f625c732e5e801675ffc5d4a28e1d310faa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/369374
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
For #47694
Change-Id: Iee4fda069a56ea4436b8aa32e2605f3349d7c154
Reviewed-on: https://go-review.googlesource.com/c/go/+/369334
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Also, move it up in the document.
Updates #47694
Change-Id: I927c4c845089a5c22e2c5b5f3de1831c04c6d990
Reviewed-on: https://go-review.googlesource.com/c/go/+/369102
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The number of involved CLs is too large (hundreds) so
no CLs are mentioned in (html) comments.
Updates #47694
Change-Id: I655d800a1e56a71e9d70a190f1c42c17baf6861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/369099
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make sure that we can import/export selects for generics.
Change-Id: Ibf36e98fc574ce9275820aa426b3e6703b0aae6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369101
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
There are currently multiple issue templates floating around for
different projects, these can sometimes be hard to find.
Fixes#29839
Change-Id: I6600b6f78842736d81d35e6a64247d00706d9e0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/366736
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also make a few small formatting fixes.
Change-Id: Iad99d030312393af3b6533f2cd00f09aea0f2a7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369074
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Enable a bunch of types2-related error tests to run successfully, so
they no longer have to be disabled in run.go.
- directive.go: split it into directive.go and directive2.go, since the
possible errors are now split across the parser and noder2, so they
can't all be reported in one file.
- linkname2.go: similarly, split it into linkname2.go and linkname3.go
for the same reason.
- issue16428.go, issue17645.go, issue47201.dir/bo.go: handle slightly
different wording by types2
- issue5609.go: handle slight different error (array length must be
integer vs. array bound too large).
- float_lit3.go: handle slightly different wording (overflows
float vs cannot convert to float)
I purposely didn't try to fix tests yet where there are extra or missing
errors on different lines, since that is not easy to make work for both
-G=3 and -G=0. In a later change, will flip to make the types2 version
match correctly, vs. the -G=0 version.
Change-Id: I6079ff258e3b90146335b9995764e3b1b56cda59
Reviewed-on: https://go-review.googlesource.com/c/go/+/368455
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Use gp.m.curg instead of the gp when recording cpu profiler stack
traces. This ensures profiler labels are captured when systemstack or similar
is executing on behalf of the current goroutine.
After this there are still rare cases of samples containing the labelHog
function, so more work might be needed. This patch should fix ~99% of the
problem.
Also change testCPUProfile interface a little to allow the new test to
re-run with a longer duration if it fails during a -short run.
Fixes#48577.
Change-Id: I3dbc9fd5af3c513544e822acaa43055b2e00dfa9
Reviewed-on: https://go-review.googlesource.com/c/go/+/367200
Trust: Michael Pratt <mpratt@google.com>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Fixes#49927
Change-Id: I8b34cf13b3bc6338309f005648ca3ee6852927f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/368954
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
PPC64's MAXWIDTH is set as 1<<60 whereas on other 64-bit
architetures it is set as 1<<50. Set to 1<<50 for consistency. The
toolchain cannot handle such large program anyway.
May fix PPC64 build.
Change-Id: Ic3972a089b2f14a96e4ded57ef218d763c924a6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/368955
Trust: Cherry Mui <cherryyz@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
On macOS 12 a new malloc implementation (nano) is used by default,
and apparently it reserves address range
0x600000000000-0x600020000000, which conflicts with the address
range that TSAN uses for Go. Work around the issue by changing the
address range slightly.
The actual change is made on LLVM at https://reviews.llvm.org/D114825 .
This CL includes syso's built with the patch applied.
Fixes#49138.
Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/367916
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
For #44853
For #47694
Change-Id: Ia76246218b1361d8bdf510bbfc5178c83cdd3eec
Reviewed-on: https://go-review.googlesource.com/c/go/+/368834
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 205237 allowed SSL_CERT_DIR to be a colon delimited list of
directories. In the case that SSL_CERT_DIR is unset, the change
also made certDirectories to all be loaded rather than stopping
after successfully reading at least one file from a directory.
This update fixes code comments on the certDirectories package
level variables to reflect current behavior.
Fixes#48808
Change-Id: Id92f875545272fc6205d9955d03ea7bf844f15eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/354140
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
