A stackObjectRecord should always be in funcdata, between gofunc
and the end of pclntab, except for the special case of
methodValueCallFrameObjs, which should always be in noptrbss.
Adjust the two loops that look for the moduledata corresponding
to a stackObjectRecord to search more precisely, rather than
relying on datap.end.
Closely based on a patch by Michael Stapelberg.
For #76038
Change-Id: I751801d8fd030af751825a67905b2a343280e7d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/728840
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
During review of CL 704615, a suggestion was made that spawning a
goroutine inside a call to secret.Do result in a panic. I agreed with
this at the time, but had missed that this had been extensively
discussed on the proposal. Revert the behavior back to what was agreed
upon.
Change-Id: Ifaa9e24bd03ecbd870ae2217137d1a9527c96842
Reviewed-on: https://go-review.googlesource.com/c/go/+/728920
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Because we dropg before emitting a trace event in preemptPark, we end up
failing to emit a status for the goroutine if this happens to be the
first event for it in the generation. We only really see this with
multiple subscribers in TestSubscribers.
This is for two reasons:
1. If we are missing a status event for a non-initial generation then
the trace parser won't validate that (an oversight, but we can only
enforce that for new traces because of this bug), and
2. If we're starting the tracer fresh, then we have a STW which
effectively guarantees that the first event for a goroutine cannot
come from preemptPark.
Therefore, we cannot observe this situation unless the first generation
manifests the bug, but prior to having flight recording and/or multiple
subscribers being able to "cut" the trace data at any point, this was
impossible.
The fix is simple: dropg only after emitting the trace event. This is
also safe, because the tracer doesn't care. The tracer will also start
taking a stack trace of the goroutine in this circumstance, but that is
also safe, since we are able to generally unwind the stack of
asynchronously preempted goroutines, and here we're at the very, very
end of asynchronous preemption where all the state to do so is already
set up.
Fixes#75665.
Change-Id: I7ee1142697d0a53b62d4c5647aa53775d2f6976a
Reviewed-on: https://go-review.googlesource.com/c/go/+/729400
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Issue #76540 reports failures in this test from the leaked goroutine
count being too small. The test makes an effort to wait for the
goroutines to leak, but there's no guarantee.
This change instead changes TestGoroutineLeakProfileConcurrency to wait
for the number of leaked goroutines to reach at least the minimum
expected before proceeding. This deflakes this particular issue.
The downside of this change is that a failure to detect leaked
goroutines due to a bug will lead to a timeout instead of an instant
failure, but this change makes an effort to log and report that it was
waiting for the goroutines to leak and timed out for that reason, so at
least the failure is more obvious.
Overall, this is still better than random flakes.
While we're here, I also make some minor stylistic changes and document
the helper functions a little more. I also noticed that checkFrames was
using the wrong *testing.T, so this change fixes that too.
Fixes#76540.
Change-Id: I0508855dc39b91f8c6b72d059ce88dbfc68fe748
Reviewed-on: https://go-review.googlesource.com/c/go/+/729280
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Update the blocklist with new linknames added in Go 1.26.
Some goroutine leak profile symbols were manually added but they
did not match the actual symbol names. Corrected.
runtime.freegc is not itself push-linknamed, so there is no need
to explicitly add it to blocklist. Keep the test, to ensure one
cannot linkname-pull freegc.
Change-Id: Ie5fd6bc191e9afa164fa79055cc39e6fa9ed4c7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/729720
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Currently TestFinalizerOrCleanupDeadlock runs a bunch of tests for both
cleanups and finalizers. However, it doesn't actually distinguish these
two cases in the subtest names. This change adds another layer of
subtest to distinguish them.
For #76523.
Change-Id: I18c2857e970cde43c18cbbcbc44e4d4ada3b2628
Reviewed-on: https://go-review.googlesource.com/c/go/+/728821
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
This reverts CL 588435.
This new API is difficult to use correctly, and in many cases cannot
be used efficiently. We're going to work on this problem a bit more.
The release notes are removed by CL 729340, since they were moved to
the x/website repository since the original CL was made.
Reopens#67546.
Change-Id: I2a2bd25f2fce5f02e4d28cd33a9cc651bf35ab50
Reviewed-on: https://go-review.googlesource.com/c/go/+/729360
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Currently we don't break out of the loop on a failure. This is
leading to timeouts trying to parse a broken trace over and over,
forever.
But there's another issue where when we try to dump the trace, we pass
only the unread portion of the bytes.Buffer.
Change-Id: I1a338eea08eaf7f592fb7dd2a736a6fe0728c62d
Reviewed-on: https://go-review.googlesource.com/c/go/+/729320
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, between the forEachP that ensures every P has a status in the
trace and readying dead Ps for the next generation, there's a big window
where GOMAXPROCS could run and change the number of Ps. In such
circumstances, P state will not get properly prepared for the next
generation, and we may fail to emit a status for a P.
This change addresses the problem by holding worldsema across both
operations. It also moves the status emission and state clearing to
before the generation transition because that makes the code *much*
clearer.
Currently we do both these things after the generation transition
targeting the next-next generation. The reason for this is to avoid an
extra forEachP (because we already handle P status in the STW for
enabling tracing to begin with) but approach is just plain harder to
reason about. Preparing the next generation before transitioning to it,
like we do for goroutines, is much clearer. Furthermore, we also need to
set up the dead P state even if we're stopping the trace, which would
mean duplicating code into both branches (if stopping the trace, then we
go non-preemptible, otherwise we do it under worldsema) which is also
less clear.
Note that with this change we no longer need to emit the P statuses
during the STW, which was probably the worse choice anyway, since
holding up the STW for an O(P) operation is worse than a forEachP we're
going to do anyway. So, this change does away with that too.
Fixes#76572.
Change-Id: Ie7908adff43a8a372cae432bcc2f4e0d6a87d7bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/729023
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the trace summarization incorrectly handles GoUndetermined by
treating it too much like GoNotExist. In particular, it should be
accumulating all the time since the start of the trace in a particular
bucket, but it doesn't, so that instead gets counted as "unknown time"
because the "creation time" is at the start of the trace.
This change fixes the problem by simply doing the accumulation. It's
very straightforward. It also side-steps some other inaccuracies, like
associating a goroutine that is being named with the current task. I
don't think this can ever actually happen in practice, but splitting up
the two cases, GoUndetermined and GoNotExist, fixes it.
Fixes#76716.
Change-Id: I3ac1557044f99c92bada2cb0e124b2192b1d6ebb
Reviewed-on: https://go-review.googlesource.com/c/go/+/728822
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
When we first implemented DIT (crypto/subtle.WithDataIndependentTiming),
we made it so that enabling DIT on a goroutine would lock that goroutine
to its current OS thread. This was done to ensure that the DIT state
(which is per-thread) would not leak to other goroutines. We also did
not make goroutines inherit the DIT state.
This change makes goroutines inherit the DIT state from their parent
at creation time. It also removes the OS thread locking when enabling
DIT on a goroutine. Instead, we now set the DIT state on the OS thread
in the scheduler whenever we switch to a goroutine that has DIT enabled,
and we unset it when switching to a goroutine that has DIT disabled.
We add a new field to G and M, ditEnabled, to track whether the G wants
DIT enabled, and whether the M currently has DIT enabled, respectively.
When the scheduler executes a goroutine, it checks these fields and
enables/disables DIT on the thread as needed.
Additionally, cgocallbackg is updated to check if DIT is enabled when
being called from C, and sets the G and M fields accordingly. This
ensures that if DIT was enabled/disabled in C, the correct state will be
reflected in the Go runtime.
The behavior as it currently stands is as follows:
- The function passed to crypto/subtle.WithDataIndependentTiming
will have DIT enabled.
- Any goroutine created within that function will inherit DIT enabled
for its lifetime. Any goroutine created from subquent goroutines will
also inherit DIT enabled for their lifetimes.
- Calling into a C function within from a goroutine with DIT enabled
will have DIT enabled.
- If the C code disables DIT, the goroutine will have DIT re-enabled
when returning to Go.
- If the C code enables DIT, the goroutine will have DIT disabled
when returning to Go if it was not previously enabled.
- Calling back into Go code from C will have DIT enabled if it was
enabled when calling into C, or if the C code enabled it.
Change-Id: I8e91e6df13bb88e56e1036e0e0e5f04efd8eebd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/726382
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The enforcement is good beyond compliance if it is correct, but I am
more nervous about accidental DoS due to mismatches between how the
caller calculates a nonce and how the enforcement expects it to be
calculated.
We need to have this enforcement in FIPS 140-3 mode, but no need to blow
ourselves up when it's off.
If all goes well, this code is unreachable anyway.
Change-Id: If73ec59ebbd283b0e5506354961a87a06a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/728504
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The cpu/go-acvp repository holding trimmed ACVP test server vectors and
validated expected results was always meant to be a temporary home. It
has now been migrated to geomys/acvp-testdata where it will continue to
be maintained by Geomys along with the FIPS module.
This commit updates acvp_test.go to use the new module location.
Change-Id: I888b125356afd0b4073cb38645486c258dea3c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/725620
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On AIX, all externally linked programs call _rt0_ppc64_aix_lib,
as seen in runtime/cgo/gcc_aix_ppc64.c. The idea is that we
only do the library initialization is isarchive is set.
However, before this CL, AIX programs would call libpreinit
before checking isarchive. The effect was that signals were
initialized twice. That caused the signal code to record that
all signals had an existing forwarding address, namely the
Go signal handler that was always installed. This caused signal
forwarding to enter an infinite loop. This caused, for example,
"go test os" to hang forever when running TestStdPipe.
Fixes#76081
Change-Id: I5555f8c5e299d45549f5ce601568dc6b3cff4ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/727820
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Each type must be representable by a finite amount of Go source code
after replacing all alias type names, value names, and embedded
interfaces (per #56103) with the RHS from their respective declarations
("expansion"); otherwise the type is invalid.
Furthermore, each type must have a finite size.
Checking for finite source after expansion is handled in decl.go.
Checking for finite size is handled in validtype.go and is delayed to
the end of type checking (unless used in unsafe.Sizeof, in which case
it is computed eagerly).
We can only construct values of valid types. Thus, while a type is
pending (on the object path and thus not yet valid), it cannot construct
a value of its own type (directly or indirectly).
This change enforces the indirect case by validating each type at value
observance (and hence upholding the invariant that values of only valid
types are created). Validation is cached on Named types to avoid
duplicate work.
As an example, consider:
type A [unsafe.Sizeof(B{})]int
type B A
Clearly, since there are no aliases, A and B have finite source. At the
site of B{}, B will be checked for finite size, recursing down the
values of B, at which point A is seen. Since A is on the object path,
there is a cycle preventing B from being proven valid before B{},
violating our invariant.
Note that this change also works for generic types.
Fixes#75918Fixes#76478
Change-Id: I76d493b5da9571780fed4b3c76803750ec184818
Reviewed-on: https://go-review.googlesource.com/c/go/+/726580
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
This commit is a REVERSE MERGE.
It merges dev.simd back into its parent branch, master.
This marks the end of development on dev.simd.
Merge List:
+ 2025-12-08 c456ab7a30 [dev.simd] all: merge master (a33bbf1) into dev.simd
+ 2025-12-08 1d8711e126 [dev.simd] internal/buildcfg: don't enable SIMD experiment by default
+ 2025-12-08 f38e968aba [dev.simd] cmd/compile: zero only low 128-bit of X15
+ 2025-12-08 144cf17d2c [dev.simd] simd, cmd/compile: move "simd" to "simd/archsimd"
+ 2025-12-08 3417b48b17 [dev.simd] simd: add carryless multiply
+ 2025-12-05 f51ee08905 [dev.simd] simd: replace checking loops with call to slice-checker
+ 2025-12-03 2b91d96941 [dev.simd] internal/buildcfg: turn GOEXPERIMENT=simd back on
Change-Id: Ife3f2ca4f6d8ce131335c0f868358db6a6a1a534
Merge List:
+ 2025-12-08 a33bbf1988 weak: fix weak pointer test to correctly iterate over weak pointers after GC
+ 2025-12-08 a88a96330f cmd/cgo: use doc link for cgo.Handle
+ 2025-12-08 276cc4d3db cmd/link: fix AIX builds after recent linker changes
+ 2025-12-08 f2d96272cb runtime/trace: update TestSubscribers to dump traces
+ 2025-12-08 4837bcc92c internal/trace: skip tests for alloc/free experiment by default
+ 2025-12-08 b5f6816cea cmd/link: generate DWARF for moduledata
+ 2025-12-08 44a39c9dac runtime: only run TestNotInGoMetricCallback when building with cgo
+ 2025-12-08 3a6a034cd6 runtime: disable TestNotInGoMetricCallback on FreeBSD + race
+ 2025-12-08 4122d3e9ea runtime: use atomic C types with atomic C functions
+ 2025-12-08 34397865b1 runtime: deflake TestProfBufWakeup
+ 2025-12-08 d4972f6295 runtime: mark getfp as nosplit
+ 2025-12-05 0d0d5c9a82 test/codegen: test negation with add/sub on riscv64
+ 2025-12-05 2e509e61ef cmd/go: convert some more tests to script tests
+ 2025-12-05 c270e71835 cmd/go/internal/vet: skip -fix on pkgs from vendor or non-main mod
+ 2025-12-05 745349712e runtime: don't count nGsyscallNoP for extra Ms in C
+ 2025-12-05 f3d572d96a cmd/go: fix race applying fixes in fix and vet -fix modes
+ 2025-12-05 76345533f7 runtime: expand Pinner documentation
+ 2025-12-05 b133524c0f cmd/go/testdata/script: skip vet_cache in short mode
+ 2025-12-05 96e142ba2b runtime: skip TestArenaCollision if we run out of hints
+ 2025-12-05 fe4952f116 runtime: relax threadsSlack in TestReadMetricsSched
+ 2025-12-05 8947f092a8 runtime: skip mayMoreStackMove in goroutine leak tests
+ 2025-12-05 44cb82449e runtime/race: set missing argument frame for ppc64x atomic And/Or wrappers
+ 2025-12-05 435e61c801 runtime: reject any goroutine leak test failure that failed to execute
+ 2025-12-05 54e5540014 runtime: print output in case of segfault in goroutine leak tests
+ 2025-12-05 9616c33295 runtime: don't specify GOEXPERIMENT=greenteagc in goroutine leak tests
+ 2025-12-05 2244bd7eeb crypto/subtle: add speculation barrier after DIT
+ 2025-12-05 f84f8d86be cmd/compile: fix mis-infer bounds in slice len/cap calculations
+ 2025-12-05 a70addd3b3 all: fix some comment issues
+ 2025-12-05 93b49f773d internal/runtime/maps: clarify probeSeq doc comment
+ 2025-12-04 91267f0a70 all: update vendored x/tools
+ 2025-12-04 a753a9ed54 cmd/internal/fuzztest: move fuzz tests out of cmd/go test suite
+ 2025-12-04 1681c3b67f crypto: use rand.IsDefaultReader instead of comparing to boring.RandReader
+ 2025-12-04 7b67b68a0d cmd/compile: use isUnsignedPowerOfTwo rather than isPowerOfTwo for unsigneds
+ 2025-12-03 2b62144069 all: REVERSE MERGE dev.simd (9ac524a) into master
Change-Id: Ia0cdf06cdde89b6a4db30ed15ed8e0bcbac6ae30
This change fixes a bug in the weak pointer test where the loop was
attempting to iterate over a nil slice (bt) instead of the weak
pointer slice (wt).
After setting bt to nil and running GC, the test should iterate over
the weak pointers to verify they've been cleared, not attempt to
iterate over the now-nil strong references.
Change-Id: Ic0425f59da132257770ed87d1bcea5d2c0a54e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/723600
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
This updates XCOFF-specific code for the recent addition
of funcdata to pclntab.
Because XCOFF puts separate symbols into separate csects,
each with their own alignment, it's important to tell the
external linker the expected alignment of each part of pclntab.
Otherwise the offsets within pclntab may change as the external
linker aligns symbols. This CL sets the correct alignment for
each pclntab child symbol, and sets pclntab's alignment to the
max of that of its children.
Tested on the GCC compile farm.
Fixes#76486
Change-Id: I77d8a90c4b4b79d80ca11ede8d9a2aa9cc89f53f
Reviewed-on: https://go-review.googlesource.com/c/go/+/725603
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Zeroing the upper part of X15 may make the CPU think it is
"dirty" and slow down SSE operations. For now, just not zeroing
the upper part, and construct a zero value on the fly if we need
a 256- or 512-bit zero value. Maybe VZEROUPPER works better than
explicitly zeroing X15, but we need to evaluate.
Long term, we probably want to move more things from SSE to AVX.
This essentially undoes CL 698237 and CL 698238, except keeping
using X15 for 128-bit zeroing for SIMD.
Change-Id: I1564e6332c4c57f9721397c92c7c734c5497534c
Reviewed-on: https://go-review.googlesource.com/c/go/+/728240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Also removes a few leftover TODOs and scraps of commented-out code
from simd development.
Updated etetest.sh to make it behave whether amd64 implies the
experiment, or not.
Fixes#76473.
Change-Id: I6d9792214d7f514cb90c21b101dbf7d07c1d0e55
Reviewed-on: https://go-review.googlesource.com/c/go/+/728220
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
