aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
AgeCommit message (Collapse)Author
2025-07-09runtime: run TestSignalDuringExec in its own process groupMichael Anthony Knyszek
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-06-27runtime: remove arbitrary 5-second timeout in TestNeedmDeadlockCherry Mui
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-06-25runtime: note custom GOMAXPROCS even if value doesn't changeMichael Pratt
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 <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-06-09runtime: use small struct TestSynctest to ensure cleanups runDamien Neil
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-29runtime, testing/synctest: breaking bubble isolation with Cond is fatalDamien Neil
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Damien Neil <dneil@google.com>
2025-05-27runtime, testing/synctest: verify cleanups/finalizers run outside bubblesDamien Neil
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 <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
2025-05-22runtime: don't spin looking for a tiny alloc address with asan or raceMichael Anthony Knyszek
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-05-21runtime: use DontUpdate testprog for DontUpdate testMichael Pratt
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 <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-21runtime: use cgroup CPU limit to set GOMAXPROCSMichael Pratt
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-21runtime: guarantee checkfinalizers test allocates in a shared tiny blockMichael Anthony Knyszek
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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-05-20runtime: mark and identify tiny blocks in checkfinalizers modeMichael Anthony Knyszek
This change adds support for identifying cleanups and finalizers attached to tiny blocks to checkfinalizers mode. It also notes a subtle pitfall, which is that the cleanup arg, if tiny-allocated, could end up co-located with the object with the cleanup attached! Oops... For #72949. Change-Id: Icbe0112f7dcfc63f35c66cf713216796a70121ce Reviewed-on: https://go-review.googlesource.com/c/go/+/662037 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-05-20runtime: annotate checkfinalizers reports with source and type infoMichael Anthony Knyszek
This change adds a new special kind called CheckFinalizer which is used to annotate finalizers and cleanups with extra information about where that cleanup or finalizer came from. For #72949. Change-Id: I3c1ace7bd580293961b7f0ea30345a6ce956d340 Reviewed-on: https://go-review.googlesource.com/c/go/+/662135 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-20runtime: add new GODEBUG checkfinalizerMichael Anthony Knyszek
This new debug mode detects cleanup/finalizer leaks using checkmark mode. It runs a partial GC using only specials as roots. If the GC can find a path from one of these roots back to the object the special is attached to, then the object might never be reclaimed. (The cycle could be broken in the future, but it's almost certainly a bug.) This debug mode is very barebones. It contains no type information and no stack location for where the finalizer or cleanup was created. For #72949. Change-Id: Ibffd64c1380b51f281950e4cfe61f677385d42a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/634599 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-05-19runtime: check for gsignal in asancall/msancall/racecallMichael Pratt
asancall and msancall are reachable from the signal handler, where we are running on gsignal. Currently, these calls will use the g0 stack in this case, but if the interrupted code was running on g0 this will corrupt the stack and likely cause a crash. As far as I know, racecall is not reachable from the signal handler, but I have updated it as well for consistency. This is the most straightforward fix, though it would be nice to eventually migrate these wrappers to asmcgocall, which already handled this case. Fixes #71395. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-race Change-Id: I6a6a636ccba826dd53e31c0e85b5d42fb1e98d12 Reviewed-on: https://go-review.googlesource.com/c/go/+/643875 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-19runtime: pass through -asan/-msan/-race to testprog testsMichael Pratt
The tests using testprog / testprogcgo are currently not covered on the asan/msan/race builders because they don't build testprog with the sanitizer flag. Explicitly pass the flag if the test itself is built with the sanitizer. There were a few tests that explicitly passed -race (even on non-race builders). These tests will now only run on race builders. For #71395. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-race Change-Id: I6a6a636ce8271246316a80d426c0e4e2f6ab99c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/643897 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-05-08runtime: schedule cleanups across multiple goroutinesMichael Anthony Knyszek
This change splits the finalizer and cleanup queues and implements a new lock-free blocking queue for cleanups. The basic design is as follows: The cleanup queue is organized in fixed-sized blocks. Individual cleanup functions are queued, but only whole blocks are dequeued. Enqueuing cleanups places them in P-local cleanup blocks. These are flushed to the full list as they get full. Cleanups can only be enqueued by an active sweeper. Dequeuing cleanups always dequeues entire blocks from the full list. Cleanup blocks can be dequeued and executed at any time. The very last active sweeper in the sweep phase is responsible for flushing all local cleanup blocks to the full list. It can do this without any synchronization because the next GC can't start yet, so we can be very certain that nobody else will be accessing the local blocks. Cleanup blocks are stored off-heap because the need to be allocated by the sweeper, which is called from heap allocation paths. As a result, the GC treats cleanup blocks as roots, just like finalizer blocks. Flushes to the full list signal to the scheduler that cleanup goroutines should be awoken. Every time the scheduler goes to wake up a cleanup goroutine and there were more signals than goroutines to wake, it then forwards this signal to runtime.AddCleanup, so that it creates another goroutine the next time it is called, up to gomaxprocs goroutines. The signals here are a little convoluted, but exist because the sweeper and the scheduler cannot safely create new goroutines. For #71772. For #71825. Change-Id: Ie839fde2b67e1b79ac1426be0ea29a8d923a62cc Reviewed-on: https://go-review.googlesource.com/c/go/+/650697 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-05-06runtime: replace mentions of "raised" with "panicked"Mark Freeman
Fixes #73526 Change-Id: I4b801cf3e54b99559e6d5ca8fdb2fd0692a0d3a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/669975 TryBot-Bypass: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Mark Freeman <mark@golang.org>
2025-04-04runtime: add thread exit plus vgetrandom stress testMichael Pratt
Add a regression test similar to the reproducer from #73141 to try to help catch future issues with vgetrandom and thread exit. Though the test isn't very precise, it just hammers thread exit. When the test reproduces #73141, it simply crashes with a SIGSEGV and no output or stack trace, which would be very unfortunate on a builder. https://go.dev/issue/49165 tracks collecting core dumps from builders, which would make this more tractable to debug. For #73141. Change-Id: I6a6a636c7d7b41e2729ff6ceb30fd7f979aa9978 Reviewed-on: https://go-review.googlesource.com/c/go/+/662636 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-03-24runtime: always show runfinq in tracebackMichael Pratt
Today, runtime.runfinq is hidden whenever runtime frames are hidden. However this frame serves as a hint that this goroutine is running finalizers, which is otherwise unclear, but can be useful when debugging issues with finalizers. Fixes #73011. Change-Id: I6a6a636cb63951fbe1fefc3554fe9cea5d0a0fb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/660295 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-20all: use exec.Command.String in test logsqmuntal
There is no need to manually construct a human-friendly string for a exec.Command. The String method does that for us. Change-Id: Iff1033478000bade9cbdc079f6143a7690374258 Reviewed-on: https://go-review.googlesource.com/c/go/+/659475 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-14runtime: only set isExtraInC if there are no Go frames leftMichael Pratt
mp.isExtraInC is intended to indicate that this M has no Go frames at all; it is entirely executing in C. If there was a cgocallback to Go and then a cgocall to C, such that the leaf frames are C, that is fine. e.g., traceback can handle this fine with SetCgoTraceback (or by simply skipping the C frames). However, we currently mismanage isExtraInC, unconditionally setting it on return from cgocallback. This means that if there are two levels of cgocallback, we end up running Go code with isExtraInC set. 1. C-created thread calls into Go function 1 (via cgocallback). 2. Go function 1 calls into C function 1 (via cgocall). 3. C function 1 calls into Go function 2 (via cgocallback). 4. Go function 2 returns back to C function 1 (returning via the remainder of cgocallback). 5. C function 1 returns back to Go function 1 (returning via the remainder of cgocall). 6. Go function 1 is now running with mp.isExtraInC == true. The fix is simple; only set isExtraInC on return from cgocallback if there are no more Go frames. There can't be more Go frames unless there is an active cgocall out of the Go frames. Fixes #72870. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I6a6a636c4e7ba75a29639d7036c5af3738033467 Reviewed-on: https://go-review.googlesource.com/c/go/+/658035 Reviewed-by: Cherry Mui <cherryyz@google.com> Commit-Queue: Michael Pratt <mpratt@google.com> 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>
2025-02-06runtime: don't duplicate reraised panic values in printpanicsDamien Neil
Change the output printed when crashing with a reraised panic value to not duplicate that value. Changes output of panicking with "PANIC", recovering, and reraising from: panic: PANIC [recovered] panic: PANIC to: panic: PANIC [recovered, reraised] Fixes #71517 Change-Id: Id59938c4ea0df555b851ffc650fe6f94c0845499 Reviewed-on: https://go-review.googlesource.com/c/go/+/645916 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19internal/synctest: new package for testing concurrent codeDamien Neil
Add an internal (for now) implementation of testing/synctest. The synctest.Run function executes a tree of goroutines in an isolated environment using a fake clock. The synctest.Wait function allows a test to wait for all other goroutines within the test to reach a blocking point. For #67434 For #69687 Change-Id: Icb39e54c54cece96517e58ef9cfb18bf68506cfc Reviewed-on: https://go-review.googlesource.com/c/go/+/591997 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-10-18runtime/testdata: fix for C23 nullptr keywordJoseph Myers
src/runtime/testdata/testprogcgo/threadprof.go contains C code with a variable called nullptr. This conflicts with the nullptr keyword in the C23 revision of the C standard (showing up as gccgo test build failures when updating GCC to use C23 by default when building C code). Rename that variable to nullpointer to avoid the clash with the keyword (any other name that's not a keyword would work just as well). Change-Id: Ida5ef371a3f856c611409884e185c3d5ded8e86c GitHub-Last-Rev: 2ec464703be0507a67a077741789a37511d197e4 GitHub-Pull-Request: golang/go#69927 Reviewed-on: https://go-review.googlesource.com/c/go/+/620955 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-09-11runtime: Goexit on C-created thread report more useful error messageCuong Manh Le
This reverts CL 609296, with the fix for failing builders. Fixes #68275 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-nocgo,gotip-darwin-amd64-nocgo,gotip-linux-ppc64_power10,gotip-linux-ppc64_power8 Change-Id: I0f539ee7b0be720642eee8885946edccd9c6e04e Reviewed-on: https://go-review.googlesource.com/c/go/+/612335 Reviewed-by: Tim King <taking@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Commit-Queue: Ian Lance Taylor <iant@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
2024-09-10Revert "runtime: Goexit on C-created thread report more useful error message"Tim King
This reverts CL 602296. Reason for revert: Failing on several builders. Change-Id: I889c566d34294032c330d4f9402300ad0d5d3bf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/611919 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-09-10runtime: Goexit on C-created thread report more useful error messageqiulaidongfeng
Fixes #68275 Change-Id: I47b7a2092f1b4d48aebf437db4e329815c956bb9 GitHub-Last-Rev: b89bf3cab7f9f7611122f535914f2788564643c5 GitHub-Pull-Request: golang/go#69126 Reviewed-on: https://go-review.googlesource.com/c/go/+/609296 Reviewed-by: Tim King <taking@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>
2024-08-16cmd/cgo: enable #cgo noescape/nocallbackdoujiang24
In Go 1.22 we added code to the go/build package to ignore #cgo noescape and nocallback directives. That permits us to enable these directives in Go 1.24. Also, this fixed a Bug in CL 497837: After retiring _Cgo_use for parameters, the compiler will treat the parameters, start from the second, as non-alive. Then, they will be marked as scalar in stackmap, which means the pointer won't be copied correctly in copystack. Fixes #56378. Fixes #63739. Change-Id: I46e773240f8a467c3c4ba201dc5b4ee473cf6e3e GitHub-Last-Rev: 42fcc506d6a7681ef24ac36a5904b57bda4b15cd GitHub-Pull-Request: golang/go#66879 Reviewed-on: https://go-review.googlesource.com/c/go/+/579955 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-24internal/runtime/exithook: make safe for concurrent os.ExitRuss Cox
Real programs can call os.Exit concurrently from multiple goroutines. Make internal/runtime/exithook not crash in that case. The throw on panic also now runs in the deferred context, so that we will see the full stack trace that led to the panic. That should give us more visibility into the flaky failures on bugs #55167 and #56197 as well. Fixes #67631. Change-Id: Iefdf71b3a3b52a793ca88d89a9c270eb50ece094 Reviewed-on: https://go-review.googlesource.com/c/go/+/588235 Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org>
2024-05-23runtime: move exit hooks into internal/runtime/exithookRuss Cox
This removes a //go:linkname usage in the coverage implementation. For #67401. Change-Id: I0602172c7e372a84465160dbf46d9fa371582fff Reviewed-on: https://go-review.googlesource.com/c/go/+/586259 Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-05-17runtime: fix coro interactions with thread-locked goroutinesMichael Anthony Knyszek
This change fixes problems with thread-locked goroutines using newcoro/coroswitch/etc. Currently, the coro paths do not consider thread-locked goroutines at all and can quickly result in broken scheduler state or lost/leaked goroutines. One possible fix to these issues is to fall back on goroutine+channel semantics, but that turns out to be fairly complicated to implement and results in significant performance cliffs. More complex thread-lock state donation tricks also result in some fairly complicated state tracking that doesn't seem worth it given the use-cases of iter.Pull (and even then, there will be performance cliffs). This change implements a much simpler, but more restrictive semantics. In particular, thread-lock state is tied to the coro at the first call to newcoro (i.e. iter.Pull). From then on, the invariant is that if the coro has any thread-lock state *or* a goroutine calling into coroswitch has any thread-lock state, that the full gamut of thread-lock state must remain the same as it was when newcoro was called (the full gamut meaning internal and external lock counts as well as the identity of the thread that was locked to). This semantics allows the common cases to be always fast, but comes with a non-orthogonality caveat. Specifically, when iter.Pull is used in conjunction with thread-locked goroutines, complex cases (passing next between goroutines or passing yield between goroutines) are likely to fail. Simple cases, where any number of iter.Pull iterators are used in a straightforward way (nested, in series, etc.) from the same goroutine, will work and will be guaranteed to be fast regardless of thread-lock state. This is a compromise for the near-term and we may consider lifting the restrictions imposed by this CL in the future. Fixes #65889. Fixes #65946. Change-Id: I3fb5791e36a61f5ded50226a229a79d28739b24e Reviewed-on: https://go-review.googlesource.com/c/go/+/583675 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Austin Clements <austin@google.com>
2024-05-17internal/trace: remove remnanats of v1 tracerCarlos Amedee
This change removes unused parts of the v1 tracer in preperation of the move of the v2 tracer into the trace package. Updates #67367 Change-Id: I3e53a8afdef72dc90c2d5b514380d1077d284bc7 Reviewed-on: https://go-review.googlesource.com/c/go/+/584537 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-08runtime: properly frame panic values in tracebacksAlan Donovan
This CL causes the printing of panic values to ensure that all newlines in the output are immediately followed by a tab, so that there is no way for a maliciously crafted panic value to fool a program attempting to parse the traceback into thinking that the panic value is in fact a goroutine stack. See https://github.com/golang/go/issues/64590#issuecomment-1932675696 + release note Updates #64590 Updates #63455 Change-Id: I5142acb777383c0c122779d984e73879567dc627 Reviewed-on: https://go-review.googlesource.com/c/go/+/581215 Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2024-03-25runtime: migrate internal/atomic to internal/runtimeAndy Pan
For #65355 Change-Id: I65dd090fb99de9b231af2112c5ccb0eb635db2be Reviewed-on: https://go-review.googlesource.com/c/go/+/560155 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ibrahim Bazoka <ibrahimbazoka729@gmail.com> Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
2024-03-21runtime: make tidExists more robustMichael Anthony Knyszek
The LockThreadExit tests in the runtime have been observed to fail after reading /proc/self/task/<tid>/stat and blindly assuming its contents followed a specific format. The parsing code is also wrong, because splitting by spaces doesn't work when the comm name contains a space. It also ignores errors without reporting them, which isn't great. This change rewrites tidExists to be more robust by using /proc/self/task/<tid>/status instead. It also modifies tidExists' signature to report an error to its caller. Its caller then prints that error. Ignoring a non-not-exist error with opening this file is the likely but unconfirmed cause of #65736 (ESRCH). This change also checks for that error explicitly as an optimistic fix. Fixes #65736. Change-Id: Iea560b457d514426da2781b7eb7b8616a91ec23b Reviewed-on: https://go-review.googlesource.com/c/go/+/567938 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-11-17runtime: gofmt -w -sJes Cok
Change-Id: I2eac85b502df9851df294f8d46c7845f635dde9b GitHub-Last-Rev: 3c8382442a0fadb355be9e4656942c2e03db2391 GitHub-Pull-Request: golang/go#64198 Reviewed-on: https://go-review.googlesource.com/c/go/+/542697 Run-TryBot: Jes Cok <xigua67damn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-11-02cmd/cgo: disable #cgo noescape/nocallback until Go 1.23Russ Cox
Go 1.21 and earlier do not understand this line, causing "go mod vendor" of //go:build go1.22-tagged code that uses this feature to fail. The solution is to include the go/build change to skip over the line in Go 1.22 (making "go mod vendor" from Go 1.22 onward work with this change) and then wait to deploy the cgo change until Go 1.23, at which point Go 1.21 and earlier will be unsupported. For #56378. Fixes #63293. Change-Id: Ifa08b134eac5a6aa15d67dad0851f00e15e1e58b Reviewed-on: https://go-review.googlesource.com/c/go/+/539235 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-10-26runtime: clear g0 stack bounds in dropmMichael Pratt
After CL 527715, needm uses callbackUpdateSystemStack to set the stack bounds for g0 on an M from the extra M list. Since callbackUpdateSystemStack is also used for recursive cgocallback, it does nothing if the stack is already in bounds. Currently, the stack bounds in an extra M may contain stale bounds from a previous thread that used this M and then returned it to the extra list in dropm. Typically a new thread will not have an overlapping stack with an old thread, but because the old thread has exited there is a small chance that the C memory allocator will allocate the new thread's stack partially or fully overlapping with the old thread's stack. If this occurs, then callbackUpdateSystemStack will not update the stack bounds. If in addition, the overlap is partial such that SP on cgocallback is close to the recorded stack lower bound, then Go may quickly "overflow" the stack and crash with "morestack on g0". Fix this by clearing the stack bounds in dropm, which ensures that callbackUpdateSystemStack will unconditionally update the bounds in needm. For #62440. Change-Id: Ic9e2052c2090dd679ed716d1a23a86d66cbcada7 Reviewed-on: https://go-review.googlesource.com/c/go/+/537695 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Bypass: Michael Pratt <mpratt@google.com>
2023-10-23runtime: allow for 10 more threads in TestWindowsStackMemory*Cuong Manh Le
CL 473415 allowed 5 more threads in TestWindowsStackMemory, to cover sysmon and any new threads in future. However, during go1.22 dev cycle, the test becomes flaky again, failing in windows-386 builder a couple of times in CL 535975 and CL 536175 (and maybe others that haven't caught). This CL increases the extra threads from 5 to 10, hopefully to make the test stable again for windows-386. The theory is that Go process load a bunch of DLLs, which may start their own threads. We could investigate more deeply if the test still be flaky with 10 extra threads. Fixes #58570 Change-Id: I255d0d31ed554859a5046fa76dfae1ba89a89aa3 Reviewed-on: https://go-review.googlesource.com/c/go/+/536058 Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-10-05runtime: support SetUnhandledExceptionFilter on Windowsqmuntal
The Windows unhandled exception mechanism fails to call the callback set in SetUnhandledExceptionFilter if the stack can't be correctly unwound. Some cgo glue code was not properly chaining the frame pointer, making the stack unwind to fail in case of an exception inside a cgo call. This CL fix that and adds a test case to avoid regressions. Fixes #50951 Change-Id: Ic782b5257fe90b05e3def8dbf0bb8d4ed37a190b Reviewed-on: https://go-review.googlesource.com/c/go/+/525475 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-09-12runtime: set _XOPEN_SORUCE_EXTENDED to 1 for aixMichael Pratt
aix requires that _XOPEN_SOURCE_EXTENDED is set to a number, not simply defined. For #62440. Change-Id: Iee221d558b5ad5b8dcb874d4d9fdf94593f7d0a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/527797 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com>
2023-09-12runtime: set _XOPEN_SOURCE_EXTENDED for netbsdMichael Pratt
If _XOPEN_SOURCE is defined, then netbsd also requires _XOPEN_SOURCE_EXTENDED to define stack_t. For #62440. Change-Id: Ib05658c3ca7fae1f6b051566e713ce7bc7c037a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/527775 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-09-12runtime: allow update of system stack bounds on callback from C threadMichael Pratt
[This is a redo of CL 525455 with the test fixed on darwin by defining _XOPEN_SOURCE, and disabled with android, musl, and openbsd, which do not provide getcontext.] Since CL 495855, Ms are cached for C threads calling into Go, including the stack bounds of the system stack. Some C libraries (e.g., coroutine libraries) do manual stack management and may change stacks between calls to Go on the same thread. Changing the stack if there is more Go up the stack would be problematic. But if the calls are completely independent there is no particular reason for Go to care about the changing stack boundary. Thus, this CL allows the stack bounds to change in such cases. The primary downside here (besides additional complexity) is that normal systems that do not manipulate the stack may not notice unintentional stack corruption as quickly as before. Note that callbackUpdateSystemStack is written to be usable for the initial setup in needm as well as updating the stack in cgocallbackg. Fixes #62440. For #62130. Change-Id: I0fe0134f865932bbaff1fc0da377c35c013bd768 Reviewed-on: https://go-review.googlesource.com/c/go/+/527715 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-09-11Revert "runtime: allow update of system stack bounds on callback from C thread"Michael Pratt
This reverts CL 525455. The test fails to build on darwin, alpine, and android. For #62440. Change-Id: I39c6b1e16499bd61e0f166de6c6efe7a07961e62 Reviewed-on: https://go-review.googlesource.com/c/go/+/527317 Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-09-11runtime: allow update of system stack bounds on callback from C threadMichael Pratt
Since CL 495855, Ms are cached for C threads calling into Go, including the stack bounds of the system stack. Some C libraries (e.g., coroutine libraries) do manual stack management and may change stacks between calls to Go on the same thread. Changing the stack if there is more Go up the stack would be problematic. But if the calls are completely independent there is no particular reason for Go to care about the changing stack boundary. Thus, this CL allows the stack bounds to change in such cases. The primary downside here (besides additional complexity) is that normal systems that do not manipulate the stack may not notice unintentional stack corruption as quickly as before. Note that callbackUpdateSystemStack is written to be usable for the initial setup in needm as well as updating the stack in cgocallbackg. Fixes #62440. For #62130. Change-Id: I7841b056acea1111bdae3b718345a3bd3961b4a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/525455 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-09-05runtime: don't let the tests leave core files behindIan Lance Taylor
Also add a check that we didn't leave any core files behind. Change-Id: I30444ef43ad1a8cc1cacd3b75280f2128e104939 Reviewed-on: https://go-review.googlesource.com/c/go/+/525175 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-08-25cmd/cgo: add #cgo noescape/nocallback annotationsdoujiang24
When passing pointers of Go objects from Go to C, the cgo command generate _Cgo_use(pN) for the unsafe.Pointer type arguments, so that the Go compiler will escape these object to heap. Since the C function may callback to Go, then the Go stack might grow/shrink, that means the pointers that the C function have will be invalid. After adding the #cgo noescape annotation for a C function, the cgo command won't generate _Cgo_use(pN), and the Go compiler won't force the object escape to heap. After adding the #cgo nocallback annotation for a C function, which means the C function won't callback to Go, if it do callback to Go, the Go process will crash. Fixes #56378 Change-Id: Ifdca070584e0d349c7b12276270e50089e481f7a GitHub-Last-Rev: f1a17b08b0590eca2670e404bbfedad5461df72f GitHub-Pull-Request: golang/go#60399 Reviewed-on: https://go-review.googlesource.com/c/go/+/497837 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-22all: remove redundant string conversions when formatting []byte with %scui fliter
Change-Id: I603051a3174b139ffb81d20d42979c7f3f04a09a Reviewed-on: https://go-review.googlesource.com/c/go/+/521136 Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-16runtime/testdata/testprog: use testenv.SyscallIsNotSupported to check ↵Bryan C. Mills
syscall.Unshare syscall.Unshare is the sort of system call that may be blocked in a container environment, and experience has shown that different container implementations choose from a variety of different error codes for blocked syscalls. In particular, the patch in https://git.alpinelinux.org/aports/tree/community/go/tests-unshare-enosys.patch seems to suggest that the container environment used to test the Go distribution on Alpine Linux returns ENOSYS instead of EPERM. The existing testenv.SyscallIsNotSupported helper checks for the kinds of error codes we have seen from containers in practice, so let's use that here. For #62053. Updates #29366. Change-Id: Ic6755f7224fcdc0cb8b25dde2d6047ceb5c3ffdf Reviewed-on: https://go-review.googlesource.com/c/go/+/520057 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2023-07-25runtime: enforce standard file descriptors open on init on unixRoland Shoemaker
On Unix-like platforms, enforce that the standard file descriptions (0, 1, 2) are always open during initialization. If any of the FDs are closed, we open them pointing at /dev/null, or fail. Fixes #60641 Change-Id: Iaab6b3f3e5ca44006ae3ba3544d47da9a613f58f Reviewed-on: https://go-review.googlesource.com/c/go/+/509020 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:52:00 +0000