go/src/internal, branch fix-runtime-test-GOMAXPROCS

internal/testenv: exclude GOMAXPROCS when building test program

2025-07-20T06:09:31Z

In the environment where GOMAXPROCS set explicitly, for example to 3 in shell profile, the runtime tests will fail with the following error, ---- ok regexp/syntax 0.428s --- FAIL: TestCgroupGOMAXPROCS (0.81s) crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe crash_test.go:208: built testprog in 796.664277ms --- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s) cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok cgroup_linux_test.go:63: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s) cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok cgroup_linux_test.go:85: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s) cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok cgroup_linux_test.go:105: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSRound (0.01s) --- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s) cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok cgroup_linux_test.go:232: output got "3\n" want "2\n" FAIL FAIL runtime 23.088s ---- This changes exclude the GOMAXPROCS when building program for testing so it does not affect the tests. Change-Id: I590d9eca57026539413cf4c93b37f624f179d534

runtime/maps: fix typo in group.go comment (instrinsified -> intrinsified)

2025-07-15T16:21:11Z

Several comments refer to bitset as 'instrinsified', which is likely a typo, because it refers to the output of the intrinsics implemented with SIMD. Change-Id: I00f26b8d8128592ee0e9dc8a1b1480c93a9542d6 GitHub-Last-Rev: 8a4236710979f2f969210e0b261bdb9ae44f3321 GitHub-Pull-Request: golang/go#74624 Reviewed-on: https://go-review.googlesource.com/c/go/+/688016 Reviewed-by: Keith Randall Auto-Submit: Keith Randall Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Keith Randall

cmd/go: disable support for multiple vcs in one module

2025-07-08T18:30:38Z

Removes the somewhat redundant vcs.FromDir, "allowNesting" argument, which was always enabled, and disallow multiple VCS metadata folders being present in a single directory. This makes VCS injection attacks much more difficult. Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior. Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue. Fixes #74380 Fixes CVE-2025-4674 Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789 Reviewed-on: https://go-review.googlesource.com/c/go/+/686515 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase Commit-Queue: Carlos Amedee Reviewed-by: Carlos Amedee

internal: make struct comment match struct name

2025-07-08T15:04:08Z

Change-Id: I85a4051bd3413bd843b17d22cf9120f615cfe8db Reviewed-on: https://go-review.googlesource.com/c/go/+/686295 Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Auto-Submit: Carlos Amedee Reviewed-by: Carlos Amedee

internal/trace: only test for sync preemption if async preemption is off

2025-07-07T20:42:35Z

Currently, the test change made for the fix to #68090 is flaky. This is because the sync-point-only goroutine that we expect to be sync preempted might only ever get async preempted in some circumstances. This change adds a variant to all trace tests to run with asyncpreemptoff=1, and the stacks test, the flaky one, only actually checks for the sync-point in the trace when async preemption is disabled. Fixes #74417. Change-Id: Ib6341bbc26921574b8f0fff6dd521ce83f85499c Reviewed-on: https://go-review.googlesource.com/c/go/+/686055 LUCI-TryBot-Result: Go LUCI Reviewed-by: Cherry Mui

internal/abi: fix comment on NonEmptyInterface

2025-07-01T15:29:57Z

Change-Id: Ia3f4e844049caf11ae67d1bd6dd48350f51c532f Reviewed-on: https://go-review.googlesource.com/c/go/+/684375 Reviewed-by: David Chase LUCI-TryBot-Result: Go LUCI Auto-Submit: Keith Randall Reviewed-by: Keith Randall

internal/goexperiment: fix godoc formatting

2025-06-30T19:14:39Z

In internal/goexperiment fix godoc formatting (list indent, add godoc links). In internal/buildcfg fix godoc for Experiment.baseline. Change-Id: I30eaba60cbf3978a375b50dda19dbb2830903bdb Reviewed-on: https://go-review.googlesource.com/c/go/+/595915 Reviewed-by: Austin Clements Reviewed-by: Michael Knyszek Auto-Submit: Austin Clements LUCI-TryBot-Result: Go LUCI

sync: disassociate WaitGroups from bubbles on Wait

2025-06-30T17:44:09Z

Fix a race condition in disassociating a WaitGroup in a synctest bubble from its bubble. We previously disassociated the WaitGroup when count becomes 0, but this causes problems when an Add call setting count to 0 races with one incrementing the count. Instead, disassociate a WaitGroup from its bubble when Wait returns. Wait must not be called concurrently with an Add call with a positive delta and a 0 count, so we know that the disassociation will not race with an Add call trying to create a new association. Fixes #74386 Change-Id: I9b519519921f7691869a64a245a5ee65d071d054 Reviewed-on: https://go-review.googlesource.com/c/go/+/684635 Reviewed-by: Michael Pratt Auto-Submit: Damien Neil LUCI-TryBot-Result: Go LUCI

runtime: account for missing frame pointer in preamble

2025-06-27T17:59:23Z

If a goroutine is synchronously preempted, then taking a frame-pointer-based stack trace at that preemption will skip PC of the caller of the function which called into morestack. This happens because the frame pointer is pushed to the stack after the preamble, leaving the stack in an odd state for frame pointer unwinding. Deal with this by marking a goroutine as synchronously preempted and using that signal to load the missing PC from the stack. On LR platforms this is available in gp.sched.lr. On non-LR platforms like x86, it's at gp.sched.sp, because there are no args, no locals, and no frame pointer pushed to the SP yet. For #68090. Change-Id: I73a1206d8b84eecb8a96dbe727195da30088f288 Reviewed-on: https://go-review.googlesource.com/c/go/+/684435 Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Nick Ripley

internal/trace: improve gc-stress test

2025-06-23T23:36:07Z

The gc-stress test is useful for trying to exercise GC-related trace events by producing a lot of them in many different situations. Unfortunately this test is flaky, because allocating in a loop can easily out-run the GC when it's trying to preempt the allocating goroutine. It's been a long standing problem that a program that allocates in a loop can outrun a GC. The problem isn't the GC persay, it's consistently correlated with a high STW time (likely a high 'stopping' time, not a 'stopped' time), suggesting that in the window of time when the garbage collector is trying to stop all goroutines, they continue to allocate. This should probably be fixed in general, but for now, let's focus on this flaky test. This CL changes the gc-stress test to (1) set a memory limit and (2) do more work in between allocations. (2) is really what makes things less flaky, but (2) unfortunately also means the GC is less exercised. That's where (1) comes in. By setting a low memory limit, we increase GC activity (in particular, assist activity). The memory limit also helps prevent the heap from totally blowing up due to the heap goal inflating from floating garbage, but it's not perfect. After this change, under stress2, this test exceeds a heap size of 500 MiB only 1 in 5000 runs on my 64-vCPU VM. Before this change, it got that big about 1/4th of the time. Fixes #74052. Change-Id: I49233c914c8b65b1d593d3953891fddda6685aec Reviewed-on: https://go-review.googlesource.com/c/go/+/683515 Reviewed-by: Carlos Amedee Auto-Submit: Michael Knyszek LUCI-TryBot-Result: Go LUCI