aboutsummaryrefslogtreecommitdiff
path: root/src/runtime
AgeCommit message (Collapse)Author
2026-03-26[release-branch.go1.26] runtime/race: apply LLVM zero-initialization fixMichael Pratt
Upstream TSAN had bug that could result in use of uninitialized memory on Go threads that don't have any TSAN events. For example, if the thread only ever runs the GC. This bug was fixed upstream in https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca. In https://go.dev/issue/78059 we have reports of actual Go crashes due to this bug. Update the prebuilt race sysos to incorporate this fix. The fix is applied as a single patch on top of the existing LLVM revisions to minimize risk of this CL, making it safe to backport. A later CL can update to a newer version of LLVM. Note that all of the patch files are identical. CL 756620 makes racebuild add a unique patch file for each architecture in the event that some arches need distinct patches. linux-loong64 failed race.bash when building the new syso, though they were just timeouts, perhaps from a slow builder. linux-riscv64 is not updated because its builder is too slow (https://go.dev/issue/78258). linux-ppc64le is not updated because its builder is missing curl (https://go.dev/issue/78210). openbsd-amd64 is not updated because its builder is missing unzip (https://go.dev/issue/78212). netbsd-amd64 is not updated because it does not have a LUCI builder (https://go.dev/issue/61121). For #78059. Fixes #78087. Cq-Include-Trybots: luci.golang.try:go1.26-linux-amd64-longtest-race,go1.26-darwin-arm64-race,go1.26-darwin-amd64-race,go1.26-freebsd-amd64-race,go1.26-windows-amd64-race,go1.26-linux-s390x-race,go1.26-linux-arm64-race,go1.26-linux-loong64 Change-Id: I5404cb88af9d86b56b385801f8a9ed106a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/757521 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Michael Pratt <mpratt@google.com> (cherry picked from commit 325eedb2a993aafb7f20738d73a1098036447917) Reviewed-on: https://go-review.googlesource.com/c/go/+/758161 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
2026-03-26[release-branch.go1.26] runtime: fix value of ENOSYS on mips from 38 to 89Jorropo
Fixes #77731 Change-Id: Iaca444e2d5f9e19fd2de38414b357b41471a668c Reviewed-on: https://go-review.googlesource.com/c/go/+/747663 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2026-03-19[release-branch.go1.26] runtime: fix printfloat, printcomplex buffer sizesMichael Pratt
The buffers added in CL 716002 for printfloat64 and printcomplex128 are too small to fit the longest formatted values. For values that are too long, AppendFloat allocates, which may cause a crash for prints in places in the runtime where allocation is not allowed. Updates #77854. Fixes #77856. Change-Id: I6a6a636cc2fc5cae9fda25f10b28fd641aa1ff28 Reviewed-on: https://go-review.googlesource.com/c/go/+/749947 Reviewed-by: Russ Cox <rsc@golang.org> 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> (cherry picked from commit cc1241f353abbac2df2baf7abe09506be27782e8) Reviewed-on: https://go-review.googlesource.com/c/go/+/750760 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-03-05[release-branch.go1.26] html/template: properly escape URLs in meta content ↵Roland Shoemaker
attributes The meta tag can include a content attribute that contains URLs, which we currently don't escape if they are inserted via a template action. This can plausibly lead to XSS vulnerabilities if untrusted data is inserted there, the http-equiv attribute is set to "refresh", and the content attribute contains an action like `url={{.}}`. Track whether we are inside of a meta element, if we are inside of a content attribute, _and_ if the content attribute contains "url=". If all of those are true, then we will apply the same URL escaping that we use elsewhere. Also add a new GODEBUG, htmlmetacontenturlescape, to allow disabling this escaping for cases where this behavior is considered safe. The behavior can be disabled by setting htmlmetacontenturlescape=0. Updates #77954 Fixes #77972 Fixes CVE-2026-27142 Change-Id: I9bbca263be9894688e6ef1e9a8f8d2f4304f5873 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3360 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3643 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/752081 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-02-09[release-branch.go1.26] runtime/pprof: fix missing Profile docsAustin Clements
CL 688335 accidentally introduced a blank line between the Profile doc comment and the type definition, causing the entire doc to get dropped. Change-Id: I97b1c0e57d142d7caea6e543a0138ed6dcd1c3fe Reviewed-on: https://go-review.googlesource.com/c/go/+/743680 Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2026-01-21runtime: remove the unused scanIdx from mspanYoulin Feng
After CL 700496, mspan.scanIdx is never used, this CL just remove it. Change-Id: I41ce9902957c0cfa6fbf26b66a2a7787b179376a Reviewed-on: https://go-review.googlesource.com/c/go/+/737220 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2026-01-15net/url: add urlmaxqueryparams GODEBUG to limit the number of query parametersDamien Neil
net/url does not currently limit the number of query parameters parsed by url.ParseQuery or URL.Query. When parsing a application/x-www-form-urlencoded form, net/http.Request.ParseForm will parse up to 10 MB of query parameters. An input consisting of a large number of small, unique parameters can cause excessive memory consumption. We now limit the number of query parameters parsed to 10000 by default. The limit can be adjusted by setting GODEBUG=urlmaxqueryparams=<n>. Setting urlmaxqueryparams to 0 disables the limit. Thanks to jub0bs for reporting this issue. Fixes #77101 Fixes CVE-2025-61726 Change-Id: Iee3374c7ee2d8586dbf158536d3ade424203ff66 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3020 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/736712 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-13runtime: rename mallocTiny* to mallocgcTinySize*Michael Matloob
This makes it easier to identify which functions are used for memory allocation by looking for functions that start with mallocgc. The Size suffix is added so that the isSpecializedMalloc function in cmd/compile/internal/ssa can distinguish between the generated functions and the mallocgcTiny function called by mallocgc, similar to the SC suffixes for the mallocgcSmallNoScanSC* and mallocgcSmallScanNoHeaderSC* functons. Change-Id: I6ad7f15617bf6f18ae5d1bfa2a0b94e86a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/735780 Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-08runtime/trace: fix documentation commentjjpinto
Correct documentation comment for mul function Change-Id: I8b90f02bf0aaba9bb5813833d1b9dd1ebb7d71f4 GitHub-Last-Rev: e91af64af9bad9cd2574dc3dd7ed88123a288be8 GitHub-Pull-Request: golang/go#77082 Reviewed-on: https://go-review.googlesource.com/c/go/+/734100 Reviewed-by: 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>
2026-01-07internal/trace: fix recorder.Write return value for header-only buffersjjpinto
Fix issue #77083 Change-Id: I9189d1e3a6efea8478224164e820f50c818abcd5 GitHub-Last-Rev: bb24cbda95f0b5b10aeae9a5ee8cbe215ba6d4eb GitHub-Pull-Request: golang/go#77092 Reviewed-on: https://go-review.googlesource.com/c/go/+/734300 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Commit-Queue: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-30runtime/secret: make tests more sturdyDaniel Morsing
Technically, the garbage collector can take an arbitrary long time until it finds a given value unreachable. Account for this fact in our zeroing tests. Updates #76586. Change-Id: Ieaf3cec99afb9204a32524ea559c5f1a280a59e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/732980 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-30all: fix some minor grammatical issues in the commentscuishuang
Change-Id: I0459f05e7f6abd9738813c65d993114e931720d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/731000 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2025-12-23runtime: improve a log message in TestCleanupLostLin Lin
Updates #76929 Change-Id: I3951b14ec979b389773f782a0a89f8277c7b9a59 Reviewed-on: https://go-review.googlesource.com/c/go/+/731680 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-23runtime: fix nGsyscallNoP accountingMichael Anthony Knyszek
CL 726964 has two bugs. One is fairly obvious. Where there was previous a decrement of nGsyscallNoP in exitsyscallTryGetP, it added a call to addGSyscallNoP. Oops. The other is more subtle. In needm we set isExtraInC to false very early. This will cause exitsyscall (via cgocallbackg) to decrement nGsyscallNoP when the thread never had a corresponding increment. (It could not have, otherwise it would not have called needm, on Linux anyway.) The fix is simple: increment nGsyscallNoP. CL 726964 actually removed this increment erroneously. I'm pretty sure I removed it because the first bug was the real issue, and removing this increment "fixed it" in the context of the test. I was right that this case was subtle, but wrong about how. Fixes #76435. Change-Id: I1ff1dfbf43bd4cf536b0965da370fee58e3f8753 Reviewed-on: https://go-review.googlesource.com/c/go/+/732320 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-22runtime: revert entry point on freebsd/arm64Rob Nichols
CL 706175 unified some arm64 entry points. However, the entry point for freebsd/arm64 is incorrect and builds now fail. This change reverts the freebsd/arm64 entry point and adds additional context for the future. Fixes #76958 Change-Id: Ib9e9b7844706f7b0ef54bd449411fefc8f10bc43 GitHub-Last-Rev: 70064d8126f8ff7e2c0e5e8d4b00177c627f4d76 GitHub-Pull-Request: golang/go#76959 Reviewed-on: https://go-review.googlesource.com/c/go/+/731980 Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-17runtime: keep track of secret allocation sizeDaniel Morsing
During a naive attempt to test the new runtime/secret package, I tried wrapping the entire handshake in a secret.Do call. This lead to a panic because some of the allocator logic had been previously untested. freeSpecial takes p and size, but they can be misleading. They don't refer to the pointer and size of the object with the special attached, but a pointer to the enclosing object and the size of the span element. The previous code did not take this into account and when passing the size to memclr would overwrite nearby objects. Fix by storing the size of the object being cleared inside the special. Fixes #76865. Change-Id: Ifae31f1c8d0609a562a37f37c45aec2f369dc6a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/730361 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2025-12-17runtime/secret: warn users about allocations, loosen guaranteesDaniel Morsing
The discussion at #76477 warranted some stronger documentation about what is expected from users of the secret package. In addition, #76764 presented a problem about when a user can expect their secrets to be deleted. Fix by loosening the guarantee to when all allocations from within a secret function have been deemed unreachable. Provide some guidance for users to steer them away from situations where allocations live on for long after the secret function has finished executing Fixes #76764. Updates #76477. Change-Id: I0cef3e7275737f32ec48f71355e588b3be26ea32 Reviewed-on: https://go-review.googlesource.com/c/go/+/728921 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-12-12runtime, cmd/link: tighten search for stackObjectRecordIan Lance Taylor
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>
2025-12-12runtime/secret: restore goroutine behavior to proposalDaniel Morsing
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>
2025-12-12runtime: dropg after emitting trace event in preemptParkMichael Anthony Knyszek
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>
2025-12-12runtime/pprof: deflake TestGoroutineLeakProfileConcurrencyMichael Anthony Knyszek
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>
2025-12-12runtime/secret: guard files with goexperimentCherry Mui
So if the goexperiment is not enabled, we don't expose an empty package. Change-Id: I57c1edac92f51b307d789d8d9bb3b505769af589 Reviewed-on: https://go-review.googlesource.com/c/go/+/729361 Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2025-12-11runtime: add extra subtest layer to TestFinalizerOrCleanupDeadlockMichael Anthony Knyszek
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>
2025-12-11runtime/trace: fix broken TestSubscribersMichael Anthony Knyszek
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>
2025-12-11runtime: prevent calls to GOMAXPROCS while clearing P trace stateMichael Anthony Knyszek
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>
2025-12-11runtime: make goroutines inherit DIT state, don't lock to OS threadRoland Shoemaker
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>
2025-12-10runtime: use correct function name in methodValueCallFrameObjs commentIan Lance Taylor
Change-Id: I029531695ae252ee912c5ab9bbb688b6ae3dc02d Reviewed-on: https://go-review.googlesource.com/c/go/+/715520 Auto-Submit: Austin Clements <austin@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-09runtime: on AIX check isarchive before calling libpreinitIan Lance Taylor
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>
2025-12-08[dev.simd] all: merge master (a33bbf1) into dev.simdCherry Mui
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
2025-12-08[dev.simd] cmd/compile: zero only low 128-bit of X15Cherry Mui
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>
2025-12-08runtime/trace: update TestSubscribers to dump tracesMichael Anthony Knyszek
CL 710755 missed this test suite. For #75665. Change-Id: Id2f1ab2eae2c20ea5056e893951a73c0b851f0eb Reviewed-on: https://go-review.googlesource.com/c/go/+/728200 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-12-08runtime: only run TestNotInGoMetricCallback when building with cgoMichael Anthony Knyszek
It seems like some platforms don't build with cgo at all, like linux/ppc64. Change-Id: Ibe5306e79899822e77d42cb3018f9f0c9ca2604c Reviewed-on: https://go-review.googlesource.com/c/go/+/728140 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-12-08runtime: disable TestNotInGoMetricCallback on FreeBSD + raceMichael Anthony Knyszek
cgo + race is not supported on FreeBSD. Change-Id: I38abeccaaabfcc104d1d5a077fb99646dc4be792 Reviewed-on: https://go-review.googlesource.com/c/go/+/728120 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-12-08runtime: use atomic C types with atomic C functionsJoel Sing
Mark types as _Atomic - fixes breakage introduced in CL 726964 across most LLVM based platforms/builders. Change-Id: I5e64b9ccb0cf5244977a787a52ee124bc03c10de Reviewed-on: https://go-review.googlesource.com/c/go/+/728040 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-12-08runtime: deflake TestProfBufWakeupNick Ripley
If CI infrastructure is oversubscribed, the profile buffer reader can be blocked long enough for the status in the traceback to be something like "[syscall, 3 minutes]", rather than the "[syscall]" we are looking for. Tweak the regexp to look for the expected state at the beginning of the status in the brackets. While we're here, clarify the possible "race" in the test, which has more to do with failing to catch a buggy implementation rather than failing for a correct implementation. Ideally if the implementation is buggy, we should see the t.Errorf at least some of the time, even if we don't see it in every run. Change-Id: Iebd5229d338dc3f973349cea6dd84c506a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/727660 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-08runtime: mark getfp as nosplitkhr@golang.org
When compiling with -l, we can't take a stack split here. Fixes #76702 Change-Id: Ieab1225c6259c7f16bb5188aa84bff615d9db2e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/728060 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-12-05runtime: don't count nGsyscallNoP for extra Ms in CMichael Anthony Knyszek
In #76435, it turns out that the new metric /sched/goroutines/not-in-go:goroutines counts C threads that have called into Go before (on Linux) as not-in-go goroutines. The reason for this is that the M is still attached to the C thread on Linux as an optimization, so we don't go through all the trouble of detaching the M and, of course, decrementing nGsyscallNoP. There's an easy fix to this accounting issue. The flag on the M, isExtraInC, says whether a thread with an extra M attached no longer has any Go on its (logical) stack. When we take the P from an M in this state, we simply just don't increment nGsyscallNoP. When it calls back into Go, we similarly skip the decrement to nGsyscallNoP. This is more efficient than alternatives, like always updating nGsyscallNoP in cgocallbackg, since that would add a new read-modify-write atomic onto that fast path. It does mean we count threads in C with a P still attached as not-in-go, but this transient in most real programs, assuming the thread indeed does not call back into Go any time soon. Fixes #76435. Change-Id: Id05563bacbe35d3fae17d67fb5ed45fa43fa0548 Reviewed-on: https://go-review.googlesource.com/c/go/+/726964 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-12-05runtime: expand Pinner documentationMichael Anthony Knyszek
This change expands the Pinner documentation based on a few points of feedback. - We need a note that the Pinner has a finalizer. - We need a note that the Pinner is safe to reuse. I also added a note that the zero value is ready to use, and expanded upon the use-cases of a Pinner. Fixes #76431. Change-Id: I312385557e67a815db05def02c1b1d7dcaa9d764 Reviewed-on: https://go-review.googlesource.com/c/go/+/726641 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>
2025-12-05runtime: skip TestArenaCollision if we run out of hintsMichael Anthony Knyszek
This seems failure mode seems to have become more common on Windows. I suspect the randomized heap base address has something to do with it, but I'm not 100% sure. What's definitely certain is that we're running out of hints, since we're seeing failures that mheap_.arenaHints is nil and GetNextArenaHint doesn't actually check that. At the very least we can check that and skip. We know that in this case there's not that much we can do. Fixes #76566. Change-Id: I8ccc8994806b6c95e3157eb296b09705637564b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/726527 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-12-05runtime: relax threadsSlack in TestReadMetricsSchedMichael Anthony Knyszek
runtime.GC is called in the test and may spin up GOMAXPROCS (proportional to the initial count) new threads. We need to be robust to this, and it happens relatively frequently on some platforms. We didn't notice this earlier since the heap is so miniscule that runtime.GC essentially finished instantly without all the threads getting spun up. Fixes #76613. Change-Id: I2af02cb090d5c1c952e4db53ad35895b6f23f638 Reviewed-on: https://go-review.googlesource.com/c/go/+/726642 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-12-05runtime: skip mayMoreStackMove in goroutine leak testsMichael Anthony Knyszek
mayMoreStackMove may introduce more scheduler chaos because of all the stack movement (not as much as mayMoreStackPreempt) so let's disable the tests here too, since we have evidence that they can produce false negatives under this configuration. Though we're not 100% sure why this is happening yet, let's at least stop the flow of flaky failures. For #75729. Change-Id: I16d13dba9a61fbd47563b21cbf188e4754f58213 Reviewed-on: https://go-review.googlesource.com/c/go/+/726526 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-12-05runtime/race: set missing argument frame for ppc64x atomic And/Or wrappersJayanth Krishnamurthy jayanth.krishnamurthy@ibm.com
The ppc64x TSAN wrappers for atomic And/Or did not initialize R6 with the Go argument frame before calling racecallatomic. Since racecallatomic expects R6 to point to the argument list and dereferences it unconditionally, this led to a nil-pointer dereference under -race. Other atomic TSAN wrappers (Load/Store/Add/Swap/CAS) already set up R6 in the expected way. This change aligns the And/Or wrappers with the rest by adding the missing R6 initialisation. This keeps the behavior consistent across all atomic operations on ppc64x. Fixes #76051. Change-Id: Iaf578449a6171a0c6f7c33ec6f64c1251297ae6d Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-ppc64_power8,gotip-linux-ppc64le_power8,gotip-linux-ppc64le_power9,gotip-linux-ppc64le_power10 Reviewed-on: https://go-review.googlesource.com/c/go/+/718560 Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Paul Murphy <paumurph@redhat.com>
2025-12-05runtime: reject any goroutine leak test failure that failed to executeMichael Anthony Knyszek
This is far more general than the regexp, which was necessary only because runTestProg doesn't return the error. This change makes runTestProg a wrapper function around a function that *does* return the error. For #76526. Change-Id: Ib3daa75eb0fe314a28a7a368474943ba470d0d4d Reviewed-on: https://go-review.googlesource.com/c/go/+/726525 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>
2025-12-05runtime: print output in case of segfault in goroutine leak testsMichael Anthony Knyszek
For #76526. Change-Id: I017e5d4c06e5de23cccc59c4c347599fecdece03 Reviewed-on: https://go-review.googlesource.com/c/go/+/726524 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-12-05runtime: don't specify GOEXPERIMENT=greenteagc in goroutine leak testsMichael Anthony Knyszek
It's enabled by default, and redundant. It'll just break when we remove the GOEXPERIMENT. Change-Id: Ic6e6a04fc2fe59b3632788c4505dd8f5305813da Reviewed-on: https://go-review.googlesource.com/c/go/+/726523 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>
2025-12-05all: fix some comment issuescuishuang
Change-Id: I5dec35b1432705b3a52859c38e758220282226af Reviewed-on: https://go-review.googlesource.com/c/go/+/726700 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-01runtime/internal/testprog: log initial SchedMetrics GOMAXPROCSMichael Pratt
For #76613. Change-Id: I6a6a636ccf28676b9cd1f820bbe42c2f3e974fee Reviewed-on: https://go-review.googlesource.com/c/go/+/725660 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>
2025-11-28runtime/secret: disable tests under memory validating modesDaniel Morsing
These tests rely on reading memory that has been freed, so any of the modes that validate memory accesses are going to fail. Disable them for now. Fixes #76586. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-msan-clang15,gotip-linux-amd64-asan-clang15,gotip-linux-amd64-race Change-Id: I14ee5dfccbafa0e4da684a95ee42acf54499b013 Reviewed-on: https://go-review.googlesource.com/c/go/+/725140 Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-11-27runtime/secret: reorganize tests to fix -buildmode=sharedDaniel Morsing
The testing assembly methods had a linkname that was implicitly satisfied during the regular build but not there during the shared build. Fix by moving the testing routine into the package itself. For good measure, section off the assembly files from the non-experiment build. Should prevent further build failures as we work on this. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest Change-Id: I2b45668e44641ae7880ff14f6402d982c7eaedd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/724001 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-11-27runtime/_mkmalloc: fix log.Fatal formatting directiveFilippo Valsorda
Change-Id: I9b9b9dbde440c3a24599efd55ef6f85a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/724281 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 08:13:23 +0000