/gc/heap/live:bytes may exceed MemStats.HeapAlloc, even when all data is
flushed, becuase the GC may double-count objects when marking them. This
is an intentional design choice that is largely inconsequential. The
runtime is already robust to it, and the condition is rare.
Fixes#60607.
Change-Id: I4da402efc24327328d2d8780e4e49961b189f0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/501858
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the spec, methods cannot be associated with a named pointer type.
Exit early with an empty method set in this case.
This matches the corresponding check in LookupFieldOrMethod;
the check is not present in (lowercase) lookupFieldOrMethod
because it (the check) doesn't apply to struct fields.
Fixes#60634.
Change-Id: Ica6ca8be6b850ea0da6f0b441fbf5b99cb0b6b17
Reviewed-on: https://go-review.googlesource.com/c/go/+/501299
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
The section on type inference has not been updated yet for Go 1.21.
Add a temporary note so that readers referred to this section from
the release notes are not confused.
Change-Id: Idc4c74d6d700f891c625289e873ad5aa9c2c5213
Reviewed-on: https://go-review.googlesource.com/c/go/+/501308
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
cmd/cover uses '//line' directives to map instrumented source files
back to the original source file and line numbers.
Line directives have no way to escape newline characters, so cmd/cover
must not be used with source file paths that contain such characters.
Updates #60167.
Change-Id: I6dc039392d59fc3a5a6121ef6ca97b0ab0da5288
Reviewed-on: https://go-review.googlesource.com/c/go/+/501577
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/cgo uses '//line' directives to map generated source
files back to the original source file and line nmubers.
The line directives have no way to escape newline characters,
so cmd/cgo must not be used if the line directives would contain
such characters.
Updates #60167.
Change-Id: I8581cea74d6c08f82e86ed87127e81252e1bf78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/501576
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Toolchain2 is only used for building toolchain3. We don't need to
build it with PGO. And building with PGO causes packages to be
built twice (one with PGO for the compiler, one without for other
programs). Disable PGO for toolchain2.
Also, I thought cmd/dist requires toolchain2 and toolchain3
compilers are identical binaries, so they need to be built in the
same way. But it doesn't.
Change-Id: Iaf49816da3dd06db79b48482c0e2435e09b512d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/501335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This only affects tests, typically manual tests, but when using trace
we're debugging and we don't want to crash because of trace itself.
No test because a test would cause trace output. Manually verified.
Fixes#60649.
Change-Id: I97abdb94db05774801ec5da56171f4a1aff35615
Reviewed-on: https://go-review.googlesource.com/c/go/+/501415
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
GODEBUG=dontfreezetheworld=1 allows goroutines to continue execution
during fatal panic. This increases the chance that tracebackothers will
encounter running goroutines that it must skip, which is expected and
fine. However, it also introduces the risk that a goroutine transitions
from stopped to running in the middle of traceback, which is unsafe and
may cause traceback crashes.
Mitigate this by halting M execution if it naturally enters the
scheduler. This ensures that goroutines cannot transition from stopped
to running after freezetheworld. We simply deadlock rather than using
gcstopm to continue keeping disturbance to scheduler state to a minimum.
Change-Id: I9aa8d84abf038ae17142f34f4384e920b1490e81
Reviewed-on: https://go-review.googlesource.com/c/go/+/501255
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Directory or file paths containing newlines may cause tools (such as
cmd/cgo) that emit "//line" or "#line" -directives to write part of
the path into non-comment lines in generated source code. If those
lines contain valid Go code, it may be injected into the resulting
binary.
(Note that Go import paths and file paths within module zip files
already could not contain newlines.)
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60167.
Fixes CVE-2023-29402.
Change-Id: I64572e9f454bce7b685d00e2e6a1c96cd33d53df
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1882606
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501226
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Enforce that linker flags which expect arguments get them, otherwise it
may be possible to smuggle unexpected flags through as the linker can
consume what looks like a flag as an argument to a preceding flag (i.e.
"-Wl,-O -Wl,-R,-bad-flag" is interpreted as "-O=-R -bad-flag"). Also be
somewhat more restrictive in the general format of some flags.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60305
Fixes CVE-2023-29404
Change-Id: I913df78a692cee390deefc3cd7d8f5b031524fc9
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1876275
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501225
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The flags that we recorded in _cgo_flags did not use any quoting,
so a flag containing embedded spaces was mishandled.
Change the _cgo_flags format to put each flag on a separate line.
That is a simple format that does not require any quoting.
As far as I can tell only cmd/go uses _cgo_flags, and it is only
used for gccgo. If this patch doesn't cause any trouble, then
in the next release we can change to only using _cgo_flags for gccgo.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Fixes#60306
Fixes CVE-2023-29405
Change-Id: I81fb5337db8a22e1f4daca22ceff4b79b96d0b4f
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1875094
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501224
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -C dir flag was added in Go 1.20.
This CL adds a new restriction: the -C must appear as the first flag on the command line.
This restriction makes finding the -C flag robust and matches the general way
people tend to think about and use the -C flag anyway.
It may break a few scripts that have been written since Go 1.20
but hopefully they will not be hard to find and fix.
(There is no strict compatibility guarantee for the command line.)
For #57001.
Change-Id: Ice2e5982c58d41eabdaef42a80d3624cde2c9873
Reviewed-on: https://go-review.googlesource.com/c/go/+/500915
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Move NewerToolchain and related code from select.go to switch.go
because it is only used for the Switch operation, not for Select.
This is a separate CL containing only the code move, separate
from any other changes.
For #57001.
Change-Id: I41cf0629b41fd55c30a1e799d857c06039ee99b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/500798
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Additional tests and bug fixes realized while writing go.dev/doc/gotoolchain (CL 500775).
- Handle go get toolchain@go1.22 (resolve to latest patch release, same as go get go@1.22).
(See modload/query.go and gover/mod.go.)
- Handle go get go@patch toolchain@patch.
(See modload/query.go and gover/mod.go.)
- Remove prefix-goVERSION-suffix form for toolchain name,
standardizing on goVERSION-suffix.
I have no good explanation for having two forms, so simplify to one.
(See vendor and gover.)
- Fail toolchain downloads when GOSUMDB=off.
Because toolchain downloads cannot always be predicted
(especially during switching rather than selection),
they cannot be listed in go.sum.
We rely on the checksum database for integrity of the download,
especially if proxied. If the checksum database is disabled,
this integrity check won't happen, so fail toolchain downloads.
(See modfetch/sumdb.go and script/gotoolchain_net.txt)
- Use names from documentation in package toolchain
(Select, Switch; SwitchTo renamed to Exec to avoid both names;
reqs.go renamed to switch.go; toolchain.go renamed to select.go.)
- Make "go env GOTOOLCHAIN" and "go env -w GOTOOLCHAIN"
work even when GOTOOLCHAIN is misconfigured.
(See special case at top of Select in select.go.)
- Clarify what goInstallVersion does
(report whether this is go install or go run pkg@version)
and explain the potential version switch more clearly.
Use the Switcher directly instead of reimplementing it.
(See select.go.)
- Document go@ and toolchain@ forms in go help get,
linking to go.dev/doc/toolchain.
(See modget/get.go.)
- Update URL of documentation in $GOROOT/go.env.
For #57001.
Change-Id: I895ef3519ff95db8710ed23b36ebaf4f648120cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/500797
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Incorporate CL 501035 for toolchain syntax changes
and a fix to a race (harmless outside tests) in sumdb client.
go get golang.org/x/mod@62c7e578 # CL 501035
go mod tidy
go mod vendor
This CL will break the cmd/go tests. The next CL fixes them.
For #57001.
Change-Id: I1fcb9799417595ecff870367f256cbc0a488934c
Reviewed-on: https://go-review.googlesource.com/c/go/+/500796
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.
Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() && getgid == getegid()).
Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
1. we check if the file descriptors 0, 1, and 2 are open, and if they
are not, we open them, pointing at /dev/null (or fail).
2. we force GOTRACKBACK=none, and generally prevent dumping of
trackbacks and registers when a program panics/aborts.
In the future we may add additional protections.
This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
Fixes#60272
Fixes CVE-2023-29403
Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501223
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is flaky with in mayMoreStackPreempt mode. This is probably
revealing a real bug in the scheduler, but since it seems to only
affect TestCrashDumpsAllThreads, which is itself testing a debug mode,
I don't think this is high priority.
Updates #55160.
Change-Id: Iac558c098930ad8d4392b1e82b34f55eaec77c48
Reviewed-on: https://go-review.googlesource.com/c/go/+/501229
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Right now, every code generator in dist has a copy of the
// Code generated by go tool dist; DO NOT EDIT.
string. Put it in one place to make sure it doesn't diverge.
Change-Id: I8b2a1904031599d7fc128b6a5d74480dee05fc89
Reviewed-on: https://go-review.googlesource.com/c/go/+/501138
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
dist's deptab is a list of changes to the automatically derived set of
package dependencies. It's as old as dist itself, and the first
version of deptab in CL 5620045 was quite complex. From the beginning,
some of the entries in deptab have been for generated files that need
to be added to the dependency set because they can't be discovered if
they don't exist. gentab is also as old as dist itself, and lists the
generated dependency files.
The interaction between deptab and gentab is rather odd. gentab
contains only base file names, not whole paths. To figure out what
files to generate, dist takes a Cartesian product of deptab and gentab
and calls the generator wherever the basename of a path in deptab
matches an entry in gentab. This perhaps made sense at the time
because some of the generated files appeared in more than one package
in deptab.
These days, deptab consists exclusively of generated files because
dist can correctly derive all other dependencies, and all of the
generated files have unique paths. This makes the Cartesian product
approach needlessly complex (and so confusing!), and means that the
only purpose served by deptab is to provide full paths for generated
files.
Furthermore, in the dist clean command, it also needed to expand the
file names in gentab to complete paths, but it did so using a
different list, cleanlist, and the same Cartesian product algorithm.
This CL drops all of this complexity by putting full paths into
gentab, which lets us delete deptab and cleanlist.
Change-Id: Ie3993983734f6da3be453bb4c17a64e22dcf3e8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/501137
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
dist clean has logic to delete command binaries from the cmd
directories in cleanlist. However, these days the only binary it could
possibly remove is "$GOROOT/src/cmd/cgo/cgo". This is clearly no
longer necessary, so remove this stale code.
When this logic was originally introduced in CL 5622058, it was driven
by cleantab (not cleanlist), which contained all of the cmd
directories, which were legion at the time because this was the era of
the [568][acgl] toolchain. CL 9154 deleted cleantab, and did the same
clean walk over the "cmd/" directories listed in buildorder. However,
buildorder was a list of packages necessary to build cmd/go, so the
only "cmd/" directory in buildorder at the time was "cmd/go". Hence,
at that CL, dist started deleting only a "$GOROOT/src/cmd/go/go"
binary. The modern cleanlist was introduced in CL 76021, as a list of
packages containing "generated files and commands". The only "cmd/"
directory in cleanlist the whole time has been "cmd/cgo" (and I'm
honestly not sure why cmd/cgo is in there), so since that CL dist has
only deleted "$GOROOT/src/cmd/cgo/cgo".
Change-Id: I1915eb938d1a0e22ae6a64e7648a21894d3e6502
Reviewed-on: https://go-review.googlesource.com/c/go/+/501136
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
There are several files in gentab that have a nil generator, which
means they used to be generated, but aren't any more, so dist should
delete them if it encounters them. However, cleaning only look for
these file names in the small number of directories listed in
cleanlist, and none of these files were originally generated into any
of the directories in cleanlist. Specifically, enam.c was generated
into $GOROOT/src/cmd/[568]l starting with CL 5620045 until CL 35740044
and the anames[5689].c files were generated into $GOROOT/src/liblink
starting with CL 35740044 and CL 120690043 until CL 6110. None of
these directories even exist any more, and if these files did somehow
exist, dist wouldn't delete them anyway.
Hence, we can safely remove these files from gentab.
Change-Id: Ifed322d64a7a81a76537fcd9fc7020c7aca48050
Reviewed-on: https://go-review.googlesource.com/c/go/+/501135
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
If we don't have exact unification, we must consider interface
unification whether one of the types is a defined (named) interface
or not. Otherwise, if one of them is named, and the other one isn't,
the code selects interface-vs-non-interface unification and possibly
uses the wrong method set as the "required" method set, leading to
(incorrect) unification failure as was the case in #60564.
We can also not simply rely on getting this right in the subsequent
switch, through the handling of *Named types.
This CL fixes this simple logic error. If there's inexact unification,
now all (non-type parameter) interface cases are handled in one place,
before the switch. After handling interfaces, we are guaranteed that
we have either no interfaces, or we have exact unification where both
types must be of the same structure.
As a consequence, we don't need special handling for named interfaces
in the *Named case of the switch anymore.
Also, move the (unbound) type parameter swap from before interface
handling to after interface handling, just before the switch which
is the code that relies on a type parameter being in x, if any.
Fixes#60564.
Change-Id: Ibf7328bece25808b8dbdb714867048b93689f219
Reviewed-on: https://go-review.googlesource.com/c/go/+/500195
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Currently, we devirtualize an interface call if the profile
indicates a concrete callee is hot on the same line, and the
concrete receiver implements the interface. But it is possible
that (likely due to another call on the same line, or possibly a
stale profile) the concrete call is to a different method.
With the current AST construction we generate correct code, as we
extract the method name from the interface call and use that to
create the concrete call. But the devirtualization decision is
based on an unrelated call in the profile.
Check the method name when finding the hottest callee, so we won't
use unrelated calls to different methods.
Change-Id: I75c026997926f21bd6cc5266d3ffe99649a9b2d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/500961
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When = is used instead of == as part of a conditional expression,
the parser message emphasizes the LHS and RHS of = by always
parenthesizing the two sides. For example, for:
if x = y {}
the error is:
cannot use assignment (x) = (y) as value
This is done to highlight the LHS and RHS in case of more complex
cases such as
if x || y = z {}
which one may incorrectly read as (x) || (y == z) rather than the
correct (x || y) = z.
This CL fine-tunes the error message a bit by only adding the
parentheses if the LHS and RHS are binary expressions.
Fixes#60599.
For #23385.
Change-Id: Ida4c8d12464cc2ac15c934f24858eb6f43cf9950
Reviewed-on: https://go-review.googlesource.com/c/go/+/500975
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
