For #66821
Change-Id: I525c308d6d6243a2bc805e819dcf40b67e52ade5
Reviewed-on: https://go-review.googlesource.com/c/go/+/608435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
As suggested by Russ Cox, making sure we see all byte values doesn't
take long and is a superset of the existing test.
Change-Id: Ifc7f18ca4189c89a3d06d0408150a2464ce5e590
Reviewed-on: https://go-review.googlesource.com/c/go/+/608397
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This mechanism ultimately calls the same JavaScript method, but being
consistent between runtime and crypto/rand lets us reuse test coverage
across them. Also, no allocations.
Cq-Include-Trybots: luci.golang.try:gotip-js-wasm
Change-Id: I035da1ed603fbcdad61945f2b57f3fb527a959fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/608396
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
OpenBSD system calls are mediated by libc anyway, and arc4random_buf()
is the preferred mechanism to obtain random bytes.
Also, rename NetBSD's function to reflect it's not actually calling
getentropy(3).
Cq-Include-Trybots: luci.golang.try:gotip-openbsd-amd64
Change-Id: Id1f3f7af16750537e2420bcf44b086de5854198c
Reviewed-on: https://go-review.googlesource.com/c/go/+/608395
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reintroduce the urandom fallback, but this time with a robust set of
tests all pointing guns at each other, including a seccomp'd respawn
simulating the lack of getrandom, to make sure the fallback both works
and is never hit unexpectedly.
Unlike the Go 1.23 fallback, the new one only triggers on ENOSYS (which
is cached by unix.GetRandom) and doesn't handle the EAGAIN errors we
never got an explanation for.
We still crash the program from Read if we have to go to /dev/urandom
and we fail to open it.
For #67001
Updates #66821
Tested on legacy SlowBots (without plan9 and illumos, which don't work):
TRY=aix-ppc64,dragonfly-amd64,freebsd-amd64,freebsd-386,netbsd-amd64
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-solaris-amd64,gotip-js-wasm,gotip-wasip1-wasm_wasmtime,gotip-wasip1-wasm_wazero,gotip-windows-amd64,gotip-windows-386,gotip-linux-386,gotip-linux-amd64-longtest-race,gotip-linux-amd64-boringcrypto
Change-Id: Idecc96a18cd6363087f5b2a4671c6fd1c41a3b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/608175
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mateusz had this idea before me in CL 578516, but it got much easier
after the recent cleanup.
It's unfortunate we lose the test coverage of batched, but the package
is significantly simpler than when we introduced it, so it should be
easier to review that everything does what it's supposed to do.
Fixes#66779
Co-authored-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Change-Id: Id35f1172e678fec184efb0efae3631afac8121d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/602498
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The fallback was reachable on
- Linux, where starting in Go 1.24 we require a kernel with
getrandom(2), see #67001.
- FreeBSD, which added getrandom(2) in FreeBSD 12.0, which we
require since Go 1.19.
- OpenBSD, which added getentropy(2) in OpenBSD 5.6, and we only
support the latest version.
- DragonFly BSD, which has getrandom(2) and where we support only
the latest version.
- NetBSD, where we switched to kern.arandom in CL 511036, available
since NetBSD 4.0.
- illumos, which has getrandom(2). (Supported versions unclear.)
- Solaris, which had getrandom(2) at least since Oracle
Solaris 11.4.
- AIX, which... ugh, fine, but that code is now in rand_aix.go.
At the end of the day the platform-specific code is just a global
func(b []byte) error, so simplified the package around that assumption.
This also includes the following change, which used to be a separate CL.
crypto/rand: improve getrandom batching and retry logic
The previous logic assumed getrandom never returned short, and then
applied stricter-than-necessary batch size limits, presumably to
avoid short returns.
This was still not sufficient because above 256 bytes getrandom(2)
can be interrupted by a signal and return short *or* it can simply
return EINTR if the pool is not initialized (regardless of buffer
size).
https://man.archlinux.org/man/getrandom.2#Interruption_by_a_signal_handler
Whether this ever failed in practice is unknown: it would have been
masked by the /dev/urandom fallback before.
Instead, we apply buffer size limits only where necessary (really,
only Solaris in practice and FreeBSD in theory) and then handle
gracefully short returns and EINTR.
Change-Id: I8677b457aab68a8fb6137a3b43538efc62eb7c93
It turns out that we now know that large getrandom calls *did* fail in
practice, falling back on /dev/urandom, because when we removed the
fallback TestBidiStreamReverseProxy with its 4KiB read started failing.
https://cr-buildbucket.appspot.com/build/8740779846954406033
For #66821
Change-Id: Iaca62997604f326501a51401cdc2659c2790ff22
Reviewed-on: https://go-review.googlesource.com/c/go/+/602495
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
normally this would not run on darwin anyway, but if there
happens to be a "pkg-config" binary, then it will. Darwin's
clang/linker does not have this flag.
Change-Id: I61929cf193c95b420441187beb8b237fa1037807
Reviewed-on: https://go-review.googlesource.com/c/go/+/616376
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Fixes#69176
Change-Id: I2e3b2a7cf7699697b957fc69ecf5200ebb137bc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/609975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Ic5580c4ee006d87b3152ae5de7b25fb532c6a33f
Reviewed-on: https://go-review.googlesource.com/c/go/+/612976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
CopyFS stipulates the permissions of the created files,
we should test them in the unit test.
* chmod x for testdata/x to test CopyFS for executable
* check the files permissions to ensure CopyFS follows the stipulated
convention
Change-Id: Id13a8ad920ad0c1ff4b801dec3bfa6869cb3101f
Reviewed-on: https://go-review.googlesource.com/c/go/+/616615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
During type inference, when comparing type parameters against their
constraints, if a type argument is completely known it must implement
its constraint. In this case, always unify the type argument's methods
against the constraint methods, if any.
Before this CL, this step was only attempted if the constraint had no
core type. That left information unused which led to type inference
failures where it should have succeeded.
Fixes#66751.
Change-Id: I71e96b71258624212186cf17ec47e67a589817b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/617896
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
To support analyzing type inference failures.
Change-Id: I47882f6b634d5fcf1834923ec372313323d31a9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/617895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Fixes#68283
Change-Id: I63bd128bd10565ce16a13b5a60d813368db26f26
Reviewed-on: https://go-review.googlesource.com/c/go/+/616339
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
For #65635
Change-Id: I4e4b0309d9139f970d6fd6b41303dfd2e0ec6236
Reviewed-on: https://go-review.googlesource.com/c/go/+/617835
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Make it obvious that numbers wasn't modified, but clone was.
Change-Id: Id8bd4ca59b7348cd218faef61abfdf12e20c89f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/617795
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts commit 5b0f8596b7.
Reason for revert: This CL breaks gotip-linux-amd64-noopt builder.
Change-Id: I3950211f05c90e4955c0785409b796987741a9f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/617715
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
I have forgotten to add it in CL 616340
Change-Id: Ia4753aa20b5e2d9978c129f2ab7d063b63a5b8e2
GitHub-Last-Rev: 2a301b12df
GitHub-Pull-Request: golang/go#69766
Reviewed-on: https://go-review.googlesource.com/c/go/+/617616
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Using MD5 for checksums in tests is an overkill, as MD5 is designed for
cryptographic purposes. Use hash/crc32 instead, which is designed for
detecting random data corruptions, aka checksums.
Change-Id: I03b30ed7f38fba2a2e59d06bd4133b495f64a013
Reviewed-on: https://go-review.googlesource.com/c/go/+/617675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Inside Google we have seen issues with QEMU user mode failing to wake a
parent waitid when this child exits with SYS_EXIT. This bug appears to
not affect SYS_EXIT_GROUP.
It is currently unclear if this is a general QEMU or specific to
Google's configuration, but SYS_EXIT and SYS_EXIT_GROUP are semantically
equivalent here, so we can use the latter here in case this is a general
QEMU bug.
For #68976.
Change-Id: I34e51088c9a6b7493a060e2a719a3cc4a3d54aa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/617417
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
I've done some more testing of the new isSending field.
I'm not able to get more than 2 bits set. That said,
with this change it's significantly less likely to have even
2 bits set. The idea here is to clear the bit before possibly
locking the channel we are sending the value on, thus avoiding
some delay and some serialization.
For #69312
Change-Id: I8b5f167f162bbcbcbf7ea47305967f349b62b0f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/617497
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Ensure that inner composite literals get a (possibly invalid) type
if something goes wrong with the enclosing composite literal.
Fixes#69092.
Change-Id: Ib1d2d529c4683ea3ab1799a818b43538e152ae8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/616616
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
While working on CL 611241 and CL 616375, I introduced a bug that wasn't
caught by any test. CL 611241 added more inline expansion at sample time
for block/mutex profile stacks collected via frame pointer unwinding.
CL 616375 then changed how inline expansion for those stacks is done at
reporting time. So some frames passed through multiple rounds of inline
expansion, and this lead to duplicate stack frames in some cases. The
stacks from TestBlockMutexProfileInlineExpansion looked like
sync.(*Mutex).Unlock
runtime/pprof.inlineF
runtime/pprof.inlineE
runtime/pprof.inlineD
runtime/pprof.inlineD
runtime.goexit
after those two CLs, and in particular after CL 616375. Note the extra
inlineD frame. The test didn't catch that since it was only looking for
a few frames in the stacks rather than checking the entire stacks.
This CL makes that test stricter by checking the entire expected stacks
rather than just a portion of the stacks.
Change-Id: I0acc739d826586e9a63a081bb98ef512d72cdc9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/617235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
I noticed in pprof that acquirem() was a bit of a hotspot. It turns out
that we can use the same trick that runtime.rand() does, and only
acquirem if we're doing something non-nosplit -- in this case, getting a
new state -- but otherwise just do getg().m, which is safe because we're
inside runtime and don't call split functions.
cpu: 11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz
│ sec/op │ sec/op vs base │
ParallelGetRandom-16 2.651n ± 4% 2.416n ± 7% -8.87% (p=0.001 n=10)
│ B/s │ B/s vs base │
ParallelGetRandom-16 1.406Gi ± 4% 1.542Gi ± 6% +9.72% (p=0.001 n=10)
Change-Id: Iae075f4e298b923e499cd01adfabacab725a8684
Reviewed-on: https://go-review.googlesource.com/c/go/+/616738
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For #68578
Change-Id: Ia9580579bfc4709945bfcf6ec3803d5d11812187
Reviewed-on: https://go-review.googlesource.com/c/go/+/606901
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For #68578
Change-Id: Idecfdbb793f46560dd69287af9170c07cf4ee973
Reviewed-on: https://go-review.googlesource.com/c/go/+/606900
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Default, use hash function in the runtime package.
If the build tag is purego or raw memory cannot be hash directly,
use reflect get each field to hash separately.
Fixes#54670
Change-Id: Ic968864c9c3c51883967d4f6dc24432385c7dc79
GitHub-Last-Rev: 5ae8a28834
GitHub-Pull-Request: golang/go#69166
Reviewed-on: https://go-review.googlesource.com/c/go/+/609761
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Remove an unexported field from ServeMux that was there only to support
some Google-internal packages. It is no longer needed.
Change-Id: I6a4d542c6c016f5a9f3d24d0c73f6ddd44c9562e
Reviewed-on: https://go-review.googlesource.com/c/go/+/616355
Reviewed-by: Chressie Himpel <chressie@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: I328760f7752f1f5ec100f151c7e13e3f804c0e10
Reviewed-on: https://go-review.googlesource.com/c/go/+/617355
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use slices.Sorted(maps.Keys(m)) to get a sorted slices of the keys in
a map.
Do not change packages built during bootstrap, as the bootstrap compiler
(currently 1.22.6) does not have the required maps and slices functions.
Change-Id: Ie35565d241fa14aca56b730a69af010127b659ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/617356
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Fixes#45669
Change-Id: Ic13523c0b3acdfc5b3e29a717bc62fde302ed8fd
GitHub-Last-Rev: 57030f26b0
GitHub-Pull-Request: golang/go#69622
Reviewed-on: https://go-review.googlesource.com/c/go/+/615676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Fixes#69708.
Change-Id: I7a0347aff75cc8dad3f6c36966b1d03822a78dc9
GitHub-Last-Rev: fcc15513e4
GitHub-Pull-Request: golang/go#69713
Reviewed-on: https://go-review.googlesource.com/c/go/+/616695
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For #46477.
Change-Id: Id02d8f67fe82228bab3f26b1cb4ebd6ee67c4634
Reviewed-on: https://go-review.googlesource.com/c/go/+/616816
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
The existing prose for struct identity did only require that two structs
"have the same sequence of fields, and if corresponding fields have the
same names, and identical types, and identical tags" for the structs to
be identical.
The implementation (forever) has also required that two corresponding
fields are either both embedded or not embedded. This is arguably part
of a struct's structure but is not explicitly specified.
This CL makes a minor change to the prose to address that.
Fixes#69472.
Change-Id: Ifa4ca69717986675642a09d03ce683ba8235efcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/616697
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
It's still pretty cryptic, but at least now instead of printing
asm: asmidx: bad address 0/2067/2068
it will print
asm: asmidx: bad address 0/BX/SP
Change-Id: I1c73c439c94c5b9d3039728db85102a818739db9
Reviewed-on: https://go-review.googlesource.com/c/go/+/611256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Update the package docs:
* The -srcdir docs were accidentally lost in CL 68590.
* The -trimpath option was added in CL 266358 but not documented.
* The options were not sorted correctly.
Fixes#69730
Change-Id: I97320e0f4fb6aa47cb03d451f028d3d9d9b560f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/616699
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Before this patch, the documentation of Dialer.Control and
ListenConfig.Control did not specify what networks would be
passed to the Control function other than the "tcp" case.
It was thus challenging to use the Control function to filter
out certain networks. This patch documents all known networks.
Fixes#69693
Change-Id: I2ab10d68c4e4fac66d51d2cc232f02cf3b305e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/617055
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Added a section about errno values vs normal go
error value semantics, and checking the return
value of C functions for error before looking at
errno.
Fixes#63485
Change-Id: Id0132a9f11e4127f4adc14e010b7e17f57a0f7d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/616264
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 615915 simplified test for issue 69434, using gcflags maymorestack to
force stack moving, making program failed with invalid stack pointer.
However, it seems that this maymorestack is broken on riscv64. At least
gotip-linux-riscv64 is currently broken.
This CL fixes this problem by using the initial approach, growing stack
size big enough to force stack moving.
Updates #69434Fixes#69714
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I95255fba884a200f75bcda34d58e9717e4a952ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/616698
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Over the years we've had various bugs in pprof stack handling resulting
in appendLocsForStack crashing because stk is too short for a cached
location. i.e., the cached location claims several inlined frames. Those
should always appear together in stk. If some frames are missing from
stk, appendLocsForStack.
If we find this case, replace the slice out of bounds panic with an
explicit panic that contains more context.
Change-Id: I52725a689baf42b8db627ce3e1bc6c654ef245d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/617135
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change adds a new environment variable GOAUTH which takes a semicolon-separated list of commands to run for authentication during go-import resolution and HTTPS module mirror protocol interactions.
This CL only supports netrc and off. Future CLs to follow will extend support to git and a custom authenticator command.
For #26232
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I6cfa4c89fd27a7a4e7d25c8713d191dc82b7e28a
Reviewed-on: https://go-review.googlesource.com/c/go/+/605256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Using a different build of Go (specifically, a different GOROOT) to
maintain the vendor directory doesn't always reproduce the same results.
This can result in unknowingly creating a vendor directory that isn't
able to build Go.
Add a note to README.vendor to point this out. Specifically, mention
that a mismatched GOROOT is an issue, and recommend using a fresh build
of Go to maintain the vendor directory.
Updates #69235
Change-Id: Id80c7607bf28bd76e43e1fdc672811c50f2bffb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/616815
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This commit amends the package documentation for the context package
and links the https://go.dev/blog/context-and-structs where the package
documentation dissuades one against embedding a context into a struct.
This is to help close the gap in understanding why this otherwise
cryptic piece of guidance is provided. The other referenced blog
article now points to go.dev instead of golang.org.
Change-Id: I0844a57bde1c03b6dddd1dd2dab2d20557d791fb
GitHub-Last-Rev: 4b039fba90
GitHub-Pull-Request: golang/go#69696
Reviewed-on: https://go-review.googlesource.com/c/go/+/616515
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Before this patch, on a system that only supports IPv6, we would
get EAFNOSUPPORT and decide that MPTCP might be available later.
The effect is that every socket tries to get MPTCP. If the system
does not support MPTCP, every socket call turns into two system calls.
Also avoid the uname if MPTCP is not supported.
For #56539
Change-Id: I628b44eda83b455f5493a9dd59076f1acea2f65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/616335
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
