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

runtime: run TestSignalDuringExec in its own process group

2025-07-09T20:34:08Z

TestSignalDuringExec sends a SIGWINCH to the whole process group. However, it may execute concurrently with other copies of the runtime tests, especially through `go tool dist`, and gdb version <12.1 has a bug in non-interactive mode where recieving a SIGWINCH causes a crash. This change modifies SignalDuringExec in the testprog to first fork itself into a new process group. To avoid issues with Ctrl+C and the new process group hanging, the new process blocks on a pipe that is passed down to it. This pipe is automatically closed when its parent exits, which should ensure that the subprocess also exits. Fixes #58932. Change-Id: I3906afa28cf8b15d22ae612d071bce7f30fc3e6c Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-noswissmap,gotip-linux-amd64-longtest-aliastypeparams,gotip-linux-amd64-longtest,gotip-linux-386-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/686875 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt

runtime: remove arbitrary 5-second timeout in TestNeedmDeadlock

2025-06-28T01:17:14Z

The NeedmDeadlock test program currently has a 5-second timeout, which is sort of arbitrary. It is long enough in regular mode (which usually takes 0.0X seconds), but not quite so for configurations like ASAN. Instead of using an arbitrary timeout, just use the test's deadline. The test program is invoked with testenv.Command, which will send it a SIGQUIT before the deadline expires. Fixes #56420 (at least for the asan builder). Change-Id: I0b13651cb07241401837ca2e60eaa1b83275b093 Reviewed-on: https://go-review.googlesource.com/c/go/+/684697 LUCI-TryBot-Result: Go LUCI Reviewed-by: Dmitri Shuralyov Reviewed-by: Dmitri Shuralyov

runtime: note custom GOMAXPROCS even if value doesn't change

2025-06-25T15:55:42Z

When an application calls runtime.GOMAXPROCS(runtime.GOMAXPROCS(0)), the runtime does not need to change the actual GOMAXPROCS value (via STW). However, this call must still transition from "automatic" to "custom" GOMAXPROCS state, thus disabling background updates. Thus this case shouldn't return quite as early as it currently does. Change-Id: I6a6a636c42f73996532bd9f7beb95e933256c9e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/683815 Reviewed-by: Michael Knyszek Reviewed-by: Carlos Amedee LUCI-TryBot-Result: Go LUCI Auto-Submit: Michael Pratt

runtime: use small struct TestSynctest to ensure cleanups run

2025-06-09T18:15:04Z

Finalizers and cleanup funcs weren't running on the windows-arm64 builder. Put finalizers/cleanups on a small struct containing a pointer rather than an *int, which fixes the problem. Also uncomment a synctest.Wait that was accidentally commented out. Fixes #73977 Change-Id: Ia6f18d74d6fccf2c5a9222317977c7458d67f158 Reviewed-on: https://go-review.googlesource.com/c/go/+/679696 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

runtime, testing/synctest: breaking bubble isolation with Cond is fatal

2025-05-29T19:49:36Z

sync.Cond.Wait is durably blocking. Waking a goroutine out of Cond.Wait from outside its bubble panics. Make this panic a fatal panic, since it leaves the notifyList in an inconsistent state. We could do some work to make this a recoverable panic, but the complexity doesn't seem worth the outcome. For #67434 Change-Id: I88874c1519c2e5c0063175297a9b120cedabcd07 Reviewed-on: https://go-review.googlesource.com/c/go/+/675617 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt Auto-Submit: Damien Neil

runtime, testing/synctest: verify cleanups/finalizers run outside bubbles

2025-05-27T21:47:13Z

Cleanup functions and finalizers must not run in a synctest bubble. If they did, a function run by the GC at an unpredictable time could unblock a bubble that synctest believes is durably blocked. Add a test verifying that cleanups and finalizers are always run by non-bubbled goroutines. (This is already the case because we never add system goroutines to a bubble.) For #67434 Change-Id: I5a48db2b26f9712c3b0dc1f425d99814031a2fc1 Reviewed-on: https://go-review.googlesource.com/c/go/+/675257 Reviewed-by: Michael Pratt LUCI-TryBot-Result: Go LUCI Auto-Submit: Damien Neil

runtime: don't spin looking for a tiny alloc address with asan or race

2025-05-22T18:31:59Z

CL 674655 modified the checkfinalizers test to spin looking for an appropriate address to trip the detector, but this doesn't work with ASAN or in race mode, which both disable the tiny allocator. Fixes #73834. Change-Id: I27416da1f29cd953271698551e9ce9724484c683 Reviewed-on: https://go-review.googlesource.com/c/go/+/675395 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt

runtime: use DontUpdate testprog for DontUpdate test

2025-05-21T20:00:42Z

This is a typo in CL 670497. The test is using the wrong testprog function. The testprog also needs to assert that GOMAXPROCS doesn't change, not that it is equal to NumCPU, for the GOMAXPROCS=4 case. For #73193. Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest Change-Id: I6a6a636cab6936aa8519e3553b70ab6641ca8010 Reviewed-on: https://go-review.googlesource.com/c/go/+/675097 Auto-Submit: Michael Pratt LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

runtime: use cgroup CPU limit to set GOMAXPROCS

2025-05-21T17:21:55Z

This CL adds two related features enabled by default via compatibility GODEBUGs containermaxprocs and updatemaxprocs. On Linux, containermaxprocs makes the Go runtime consider cgroup CPU bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup limit is lower than the number of logical CPUs available, then the cgroup limit takes precedence. On all OSes, updatemaxprocs makes the Go runtime periodically recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has changed. If GOMAXPROCS is set manually, this update does not occur. This is intended primarily to detect changes to cgroup limits, but it applies on all OSes because the CPU affinity mask can change as well. The runtime only considers the limit in the leaf cgroup (the one that actually contains the process), caching the CPU limit file descriptor(s), which are periodically reread for updates. This is a small departure from the original proposed design. It will not consider limits of parent cgroups (which may be lower than the leaf), and it will not detection cgroup migration after process start. We can consider changing this in the future, but the simpler approach is less invasive; less risk to packages that have some awareness of runtime internals. e.g., if the runtime periodically opens new files during execution, file descriptor leak detection is difficult to implement in a stable way. For #73193. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98 Reviewed-on: https://go-review.googlesource.com/c/go/+/670497 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

runtime: guarantee checkfinalizers test allocates in a shared tiny block

2025-05-21T16:50:31Z

Currently the checkfinalizers test (TestDetectCleanupOrFinalizerLeak) only *tries* to ensure the tiny alloc with a cleanup attached shares a block with other objects. However, what it does is insufficient, because it could get unlucky and have the last object allocated be the first object of a new block. This change changes the test to guarantee that a tiny object is not at the start of a fresh block by looking at the alignment of the object's pointer. If the object's pointer is odd, then that's good enough to know that it shares a block with something else, since the blocks themselves are aligned to a much higher power of two. This fixes a failure I've seen on the builders. Fixes #73810. Change-Id: Ieafdbb9cccb0d2dc3659a9a5d9d9233718461635 Reviewed-on: https://go-review.googlesource.com/c/go/+/674655 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt