forked from golang/go
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go1.23 with memory regions patch #1
Draft
csgourav
wants to merge
69
commits into
cockroachdb:master
Choose a base branch
from
csgourav:gourav-go1.23-memory-regions
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
go1.23 with memory regions patch #1
csgourav
wants to merge
69
commits into
cockroachdb:master
from
csgourav:gourav-go1.23-memory-regions
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change-Id: Ib335bc903e2b8d5b7be6a158a6debe5db48e79a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/593535 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
…gonfly CL 219638 added UTIME_OMIT values for various systems. The value for DragonFly BSD appears to be incorrect. The correct value is -2 (see references below), while -1 is used for UTIME_NOW. As a result, timestamp is changed to the current time instead of not touching. This should have been caught by the accompanying test case, TestChtimesWithZeroTimes, but its failures are essentially skipped on dragonfly (this is being fixed separately in a followup CL 591535). Improve formatting while at it. References: - https://github.com/DragonFlyBSD/DragonFlyBSD/blob/965b380e9609/sys/sys/stat.h#L284 - https://go.googlesource.com/sys/+/refs/tags/v0.20.0/unix/zerrors_dragonfly_amd64.go#1421 Change-Id: I432360ca982c84b7cd70d0cf01d860af9ff985fa Reviewed-on: https://go-review.googlesource.com/c/go/+/589496 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Commit-Queue: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/593796 Reviewed-by: Michael Pratt <mpratt@google.com>
Type parameters on aliases are now allowed after golang#46477 accepted. Updates golang#46477 Fixes golang#68054 Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/593715 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/593797 Reviewed-by: Michael Pratt <mpratt@google.com>
…econtentkeepheaders The pre-Go 1.23 behavior is httpservecontentkeepheaders=1. For golang#66343 Change-Id: If6f92853b38522f19a8908ff11ac49b12f3dc3e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/593775 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/593795 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: Ied4bb63f49d13bd7d421cf9cb269220974641b89 Reviewed-on: https://go-review.googlesource.com/c/go/+/593897 Auto-Submit: David Chase <drchase@google.com> 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: Gopher Robot <gobot@golang.org>
…ch.go1.23 Merge List: + 2024-07-15 8f1ec59 strings: re-introduce noescape wrapper + 2024-07-15 5d36bc1 net/http: document io.Seeker requirement for fs.FS arguments + 2024-07-12 071b8d5 cmd: vendor golang.org/x/telemetry@268b4a8ec2d7 + 2024-07-12 4e77872 go/types: fix assertion failure when range over int is not permitted + 2024-07-12 8bc32ab os: clean up after TestIssue60181 + 2024-07-11 b31e9a6 unsafe: say "functions like syscall.Syscall", not only Syscall + 2024-07-11 a71bb57 all: make struct comments match struct names + 2024-07-11 611f18c strings: more cross-references in docstrings + 2024-07-11 08a6e08 database/sql/driver: fix name in comment + 2024-07-11 dfaaa91 os: clarify that IsNotExist, IsExist, IsPermission and IsTimeout work with nil errors + 2024-07-10 5881d85 crypto/tls: add support for -expect-no-hrr to bogo_shim_test + 2024-07-10 b304067 math: remove riscv64 assembly implementations of rounding + 2024-07-10 70e453b context: handle nil values for valueCtx.String() + 2024-07-09 183a40d runtime: avoid multiple records with identical stacks from MutexProfile + 2024-07-09 e89e880 crypto/tls: add support for -reject-alpn and -decline-alpn flags to bogo_shim_test + 2024-07-09 73186ba crypto/internal/cryptotest: add common tests for the hash.Hash interface + 2024-07-08 87ec2c9 testing: remove call to os.Exit in documentation for TestMain + 2024-07-08 6d89b38 unsafe: clarify when String bytes can be modified + 2024-07-07 5565462 cmd/dist: remove iter,slices,maps test on GOEXPERIMENT=rangefunc + 2024-07-07 b43d6c5 io: add test for Pipe constructor allocations + 2024-07-07 d0146bd os/exec: only use cachedLookExtensions if Cmd.Path is unmodified + 2024-07-05 ad77cef cmd/compile: correct RewriteMultiValueCall fatal message + 2024-07-05 be15292 cmd/compile: fix ICE when compiling global a, b = f() + 2024-07-03 82c1434 cmd/link: don't disable memory profiling when pprof.WriteHeapProfile is used + 2024-07-03 7d19d50 cmd/cgo: read CGO_LDFLAGS environment variable + 2024-07-03 5f50b1e cmd/compile: fix mis-compilation when switching over channels + 2024-07-03 71f9dbb cmd/compile: emit error message on mismatch import path + 2024-07-03 148755a cmd/link: document -checklinkname option + 2024-07-02 f12ac5b time: fix time zone parsing when format includes time zone seconds + 2024-07-02 09aeb6e os: add TODO about removing test exception + 2024-07-01 94982a0 cmd/go/internal/workcmd: remove a potentially confusing statement + 2024-07-01 f71c00b cmd/link: align .reloc block starts by 32 bits for PE target + 2024-07-01 d3c93f2 cmd/go: update go clean help message + 2024-07-01 cdbf5f2 sync: refer to Locker interface methods in RWMutex.RLocker doc + 2024-07-01 c33144c runtime: fix nil pointer in TestGoroutineParallelism2 when offline + 2024-06-28 82c371a cmd/compile: drop internal range-over-func vars from DWARF output + 2024-06-28 773767d net/http: avoid appending an existing trailing slash to path again + 2024-06-28 7f90b96 cmd/compile: don't elide zero extension on top of signed values + 2024-06-27 ea537cc cmd/go/internal/help: add documentation for language version downgrading + 2024-06-27 b0927fd slices: update docs for All, Backward, Values + 2024-06-26 5a18e79 cmd/link: don't skip code sign even if dsymutil didn't generate a file + 2024-06-26 5f319b7 cmd/link: don't let dsymutil delete our temp directory + 2024-06-26 a2e90be os: rewrite TestChtimesWithZeroTimes + 2024-06-25 90bcc55 crypto/tls: apply QUIC session event flag to QUICResumeSession events + 2024-06-25 b1fd047 cmd/internal/obj/arm64: fix return with register + 2024-06-25 b3b4556 cmd/compile: update README to reflect dead code elimination changes + 2024-06-24 68315bc cmd: run go mod tidy after CL 593684 + 2024-06-24 f214a76 cmd/vendor: vendor x/telemetry@38a4430 + 2024-06-24 29b1a67 net/http: document that Request.Clone does not deep copy Body + 2024-06-24 cf54a3d crypto/tls: replay test recordings without network + 2024-06-24 b98803e os: TestChtimes: separate hasNoatime + 2024-06-24 0def9d5 cmd/internal/obj/arm64: Enable arm64 assembler tests for cross-compiler builds + 2024-06-24 085cf0f net/netip: add test that Compare and reflect.DeepEqual match + 2024-06-24 740043f net/netip: unexport fields of addrDetail + 2024-06-23 e8ee1dc cmd/link/internal/ld: handle "\r" in MinGW "--print-prog-name" output + 2024-06-22 44f1870 cmd/link: handle dynamic import variables on Darwin in plugin mode + 2024-06-21 0af2148 cmd: vendor golang.org/x/telemetry@a740542 + 2024-06-21 cb3b343 doc/next: delete + 2024-06-21 d79c350 cmd/internal: separate counter package from telemetry package + 2024-06-21 52ce25b cmd/vendor: pull in golang.org/x/telemetry@b4de734 + 2024-06-21 fed2c11 iter: minor doc comment updates + 2024-06-21 d73a8a2 cmd/cgo: fail on v, err := C.fn when fn is a builtin function + 2024-06-21 1b4f1dc os: improve newFile, rm newDir + 2024-06-21 72e2220 encoding/json: clarify the map's key type for Unmarshal + 2024-06-21 e9a306e types2, go/types: correct NewTypeParam documentation + 2024-06-21 6fea409 text/template/parse: fix handling of assignment/declaration in PipeNode.String + 2024-06-21 d67839f crypto/tls: add support for -expect-version to bogo_shim_test + 2024-06-21 2011294 sync/atomic: correct result names for Or methods + 2024-06-21 20b79fd time: provide non-default metric for asynctimerchan + 2024-06-20 9d33956 internal/godebugs: fix old value for httpservecontentkeepheaders + 2024-06-20 477ad7d cmd/compile: support generic alias type + 2024-06-18 4f77a83 internal/syscall/unix: fix UTIME_OMIT for dragonfly Change-Id: I3864b03b8c377e8fe82014eee96dc7b77aea64e2
…ch.go1.23 Merge List: + 2024-07-15 6948b4d Revert "runtime: avoid multiple records with identical stacks from MutexProfile" Change-Id: I94d1f445b0304eb4355ef6e91bf9f8585abfe0f8
Change-Id: I73a3f2e680a84aa698c6f64b1e924bb1b9a85a89 Reviewed-on: https://go-review.googlesource.com/c/go/+/598555 TryBot-Bypass: Carlos Amedee <carlos@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Carlos Amedee <carlos@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org>
…ch.go1.23 Merge List: + 2024-07-22 5e8a731 README: fix CC BY license name + 2024-07-22 a799fa5 slices: explicitly document nil and empty slice equality + 2024-07-22 f0de94f cmd/compile: don't inline runtime functions in -d=checkptr build + 2024-07-19 3959d54 runtime: mark lockWithRankMayAcquire as nosplit + 2024-07-17 70491a8 maps: document handling of non-reflexive keys + 2024-07-17 7321aa9 cmd: vendor golang.org/x/telemetry@0b706e1 + 2024-07-17 420037b os: don't try to signal PID -1 on Unix + 2024-07-17 87abb4a runtime: avoid multiple records with identical stacks from MutexProfile + 2024-07-17 8c88f0c cmd/cgo/internal/testcarchive: remove 1-minute timeout + 2024-07-17 fc51e50 math/big: fix comment typo in natdiv.go + 2024-07-17 90c6558 internal/bytealg: extend memchr result correctly on wasm + 2024-07-16 3557118 cmd/internal/cov: close counter data files eagerly + 2024-07-16 f2bcab5 regexp: more cross-references in docstrings + 2024-07-16 9915b87 bytes: more cross-references in docstrings + 2024-07-16 97ccc22 math/big: use lists in docstrings + 2024-07-16 66e940b math/big: more cross-references in docstrings + 2024-07-16 0dae393 encoding/binary: use list format in docstrings + 2024-07-16 451a284 strings,bytes,regexp: use lists in Split* docstrings + 2024-07-16 b4a92f5 crypto/tls: add exclude tls flags to bogo_shim_test + 2024-07-16 3bfbfa8 encoding/json: document compact json output in Encoder.Encode + 2024-07-16 d5479e1 net: document ParseIP always returns IPv6 addresses + 2024-07-16 5c7f541 archive/zip: document handling of duplicate names in Writer.Create + 2024-07-16 6b97448 sort: add example for Find + 2024-07-16 8b48290 cmd/compile: fix recursive generic interface instantiation + 2024-07-15 959b3fd flag: add FlagSet example Change-Id: I0e7cac2f1cef42ccf3d392c57dad793ca3b08b11
…destination Also clarify the permissions of created files, and note that CopyFS will not overwrite files. Update a few places in documentation to use 0oXXX for octal consts. For golang#62484 Change-Id: I208ed2bde250304bc7fac2b93963ba57037e791e Reviewed-on: https://go-review.googlesource.com/c/go/+/600775 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 910e6b5) Reviewed-on: https://go-review.googlesource.com/c/go/+/600815 Reviewed-by: Ian Lance Taylor <iant@google.com>
…rting generic type alias When GOEXPERIMENT=aliastypeparams is set, type aliases may have type parameters. The compiler export data doesn't export that type parameter information yet, which leads to an index-out-of-bounds panic when a client package imports a package with a general type alias and then refers to one of the missing type parameters. This CL detects this specific case and panics with a more informative panic message explaining the shortcoming. The change is only in effect if the respective GOEXPERIMENT is enabled. Manually tested. No test addded since this is just a temporary fix (Go 1.24 will have a complete implementation), and because the existing testing framework doesn't easily support testing that a compilation panics. Together with @taking and input from @rfindley. For golang#68526. Change-Id: I24737b153a7e2f9b705cd29a5b70b2b9e808dffc Reviewed-on: https://go-review.googlesource.com/c/go/+/601035 Reviewed-by: Tim King <taking@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
…type with generic alias The typechecker is assuming that alias instances cannot be reached from a named type. However, when type parameters on aliases are permited, it can happen. This CL changes the typechecker to propagate the correct named instance is being expanded. Updates golang#46477 Fixes golang#68580 Change-Id: Id0879021f4640c0fefe277701d5096c649413811 Reviewed-on: https://go-review.googlesource.com/c/go/+/601115 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/601116
The flakes were introduced by me in CL 586655. It's unclear why only FreeBSD seems affected, maybe other TCP stacks handle sending on a half-closed connection differently, or aren't as quick to propagate the RST over localhost. Updates golang#68155 Change-Id: I32a1b474a7d6531dbab93910c23568b867629e8c Reviewed-on: https://go-review.googlesource.com/c/go/+/602635 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
…1 or greater Only honor //go:build language version downgrades if the version specified is 1.21 or greater. Before 1.21 the version in //go:build lines didn't have the meaning of setting the file's language version. This fixes an issue that was appearing in GOPATH builds: Go 1.23 started providing -lang versions to the compiler in GOPATH mode (among other places) which it wasn't doing before. For example, take a go file with a //go:build line specifying go1.10. If that file used a 1.18 feature, that use would compile fine with a Go 1.22 toolchain. But, before this change, it would produce an error when compiling with the 1.23 toolchain because it set the language version to 1.10 and disallowed the 1.18 feature. This breaks backwards compatibility: when the build tag was added, it did not have the meaning of restricting the language version. Fixes golang#68658 Change-Id: I4ac2b45a981cd019183d52ba324ba8f0fed93a8e Reviewed-on: https://go-review.googlesource.com/c/go/+/603895 Reviewed-by: Robert Griesemer <gri@google.com> Commit-Queue: Michael Matloob <matloob@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Matloob <matloob@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/604935
…n if 1.21 or greater" This reverts commit CL 604935. Reason for revert: The team has decided that this change will be added to a point release. Change-Id: I1c1032b881c3a98312a4753b9767cb7c8eed9e09 Reviewed-on: https://go-review.googlesource.com/c/go/+/605096 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Change-Id: I2b0514157b85ca61f9f6b8931df6ac874598a045 Reviewed-on: https://go-review.googlesource.com/c/go/+/605215 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
It appears that some builders (notably, linux-arm) have some additional security software installed, which apparently reads the files created by tests. As a result, test file atime is changed, making the test fail like these: === RUN TestChtimesOmit ... os_test.go:1475: atime mismatch, got: "2024-07-30 18:42:03.450932494 +0000 UTC", want: "2024-07-30 18:42:02.450932494 +0000 UTC" === RUN TestChtimes ... os_test.go:1539: AccessTime didn't go backwards; was=2024-07-31 20:45:53.390326147 +0000 UTC, after=2024-07-31 20:45:53.394326118 +0000 UTC According to inode(7), atime is changed when more than 0 bytes are read from the file. So, one possible solution to these flakes is to make the test files empty, so no one can read more than 0 bytes from them. For golang#68687 For golang#68663 Fixes golang#68812 Change-Id: Ib9234567883ef7b16ff8811e3360cd26c2d6bdab Reviewed-on: https://go-review.googlesource.com/c/go/+/604315 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Commit-Queue: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> (cherry picked from commit 84266e1) Reviewed-on: https://go-review.googlesource.com/c/go/+/604196
…o disallow rewriting existing files does not exist On Linux, a call to creat() is equivalent to calling open() with flags equal to O_CREAT|O_WRONLY|O_TRUNC, which applies to other platforms as well in a similar manner. Thus, to force CopyFS's behavior to comply with the function comment, we need to replace O_TRUNC with O_EXCL. Fixes golang#68907 Change-Id: I3e2ab153609d3c8cf20ce5969d6f3ef593833cd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/606095 Auto-Submit: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit aa5d672) Reviewed-on: https://go-review.googlesource.com/c/go/+/606415
…type in Make Currently the first thing Make does it get the abi.Type of its argument, and uses abi.TypeOf to do it. However, this has a problem for interface types, since the type of the value stored in the interface value will bleed through. This is a classic reflection mistake. Fix this by implementing and using a generic TypeFor which matches reflect.TypeFor. This gets the type of the type parameter, which is far less ambiguous and error-prone. For golang#68990. Fixes golang#68992. Change-Id: Idd8d9a1095ef017e9cd7c7779314f7d4034f01a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/607355 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 755c18e) Reviewed-on: https://go-review.googlesource.com/c/go/+/607435 Reviewed-by: Ian Lance Taylor <iant@google.com>
…dle *Alias types Named.cleanup is called at the end of type-checking to ensure that a named type is fully set up; specifically that it's underlying field is not (still) a Named type. Now it can also be an *Alias type. Add this case to the respective type switch. Fixes golang#68894. Change-Id: I29bc0024ac9d8b0152a3d97c82dd28d09d5dbd66 Reviewed-on: https://go-review.googlesource.com/c/go/+/605977 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/606656
…create in _rt0_ppc64_aix_lib The AIX ABI requires allocating parameter save space when calling a function, even if the arguments are passed via registers. gcc sometimes uses this space. In the case of the cgo c-archive tests, it clobbered the storage space of argc/argv which prevented the test program from running the expected test. Fixes golang#68973 Change-Id: I8a267b463b1abb2b37ac85231f6c328f406b7515 Reviewed-on: https://go-review.googlesource.com/c/go/+/606895 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/607195 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
…) if fileVersion present Change the rules for how //go:build "file versions" are applied: instead of considering whether a file version is an upgrade or downgrade from the -lang version, always use max(fileVersion, go1.21). This prevents file versions from downgrading the version below go1.21. Before Go 1.21 the //go:build version did not have the meaning of setting the file's langage version. This fixes an issue that was appearing in GOPATH builds: Go 1.23.0 started providing -lang versions to the compiler in GOPATH mode (among other places) which it wasn't doing before, and it set -lang to the toolchain version (1.23). Because the -lang version was greater than go1.21, language version used to compile the file would be set to the //go:build file version. //go:build file versions below 1.21 could cause files that could previously build to stop building. For example, take a Go file with a //go:build line specifying go1.10. If that file used a 1.18 feature, that use would compile fine with a Go 1.22 toolchain. But it would produce an error when compiling with the 1.23.0 toolchain because it set the language version to 1.10 and disallowed the 1.18 feature. This breaks backwards compatibility: when the build tag was added, it did not have the meaning of restricting the language version. For golang#68658 Fixes golang#69094 Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece Reviewed-on: https://go-review.googlesource.com/c/go/+/607955 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> (cherry picked from commit aeac0b6) Reviewed-on: https://go-review.googlesource.com/c/go/+/608935
…inter As of CL 580255, the runtime tracks the frame pointer (or base pointer, bp) when entering syscalls, so that we can use fpTracebackPCs on goroutines that are sitting in syscalls. That CL mostly got things right, but missed one very subtle detail. When calling from Go->C->Go, the goroutine stack performing the calls when returning to Go is free to move around in memory due to growth, shrinking, etc. But upon returning back to C, it needs to restore gp.syscall*, including gp.syscallsp and gp.syscallbp. The way syscallsp currently gets updated is automagically: it's stored as an unsafe.Pointer on the stack so that it shows up in a stack map. If the stack ever moves, it'll get updated correctly. But gp.syscallbp isn't saved to the stack as an unsafe.Pointer, but rather as a uintptr, so it never gets updated! As a result, in rare circumstances, fpTracebackPCs can correctly try to use gp.syscallbp as the starting point for the traceback, but the value is stale. This change fixes the problem by just storing gp.syscallbp to the stack on cgocallback as an unsafe.Pointer, like gp.syscallsp. It also adds a comment documenting this subtlety; the lack of explanation for the unsafe.Pointer type on syscallsp meant this detail was missed -- let's not miss it again in the future. Now, we have a fix, what about a test? Unfortunately, testing this is going to be incredibly annoying because the circumstances under which gp.syscallbp are actually used for traceback are non-deterministic and hard to arrange, especially from within testprogcgo where we don't have export_test.go and can't reach into the runtime. So, instead, add a gp.syscallbp check to reentersyscall and entersyscallblock that mirrors the gp.syscallbp consistency check. This probably causes some miniscule slowdown to the syscall path, but it'll catch the issue without having to actually perform a traceback. For golang#69085. Fixes golang#69087. Change-Id: Iaf771758f1666024b854f5fbe2b2c63cbe35b201 Reviewed-on: https://go-review.googlesource.com/c/go/+/608775 Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 54fe0fd) Reviewed-on: https://go-review.googlesource.com/c/go/+/608835
Unalias the ~T terms during underIs. Before, if T was an alias of U, it may pass T to the iteration function. The iterator function expects an underlying type, under(U), to be passed. This caused several bugs where underIs is used without eventually taking the underlying type. Fixes golang#68905 Change-Id: Ie8691d8dddaea00e1dcba94d17c0f1b021fc49a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/606075 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Findley <rfindley@google.com> (cherry picked from commit 1a90dcd) Reviewed-on: https://go-review.googlesource.com/c/go/+/607635
…and Close The current implementation has a panic when the database is closed concurrently with a new connection attempt. connRequestSet.CloseAndRemoveAll sets connRequestSet.s to a nil slice. If this happens between calls to connRequestSet.Add and connRequestSet.Delete, there is a panic when trying to write to the nil slice. This is sequence is likely to occur in DB.conn, where the mutex is released between calls to db.connRequests.Add and db.connRequests.Delete This change updates connRequestSet.CloseAndRemoveAll to set the curIdx to -1 for all pending requests before setting its internal slice to nil. CloseAndRemoveAll already iterates the full slice to close all the request channels. It seems appropriate to set curIdx to -1 before deleting the slice for 3 reasons: 1. connRequestSet.deleteIndex also sets curIdx to -1 2. curIdx will not be relevant to anything after the slice is set to nil 3. connRequestSet.Delete already checks for negative indices For golang#68949 Fixes golang#69041 Change-Id: I6b7ebc5a71b67322908271d13865fa12f2469b87 GitHub-Last-Rev: 7d26691 GitHub-Pull-Request: golang#68953 Reviewed-on: https://go-review.googlesource.com/c/go/+/607238 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Commit-Queue: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit 08707d6) Reviewed-on: https://go-review.googlesource.com/c/go/+/609255
…ranch.go1.23-vendor Update x/telemetry to fix golang#68976 and golang#68946. Commands run: go get golang.org/x/telemetry@internal-branch.go1.23-vendor go mod tidy go mod vendor Fixes golang#68994. Fixes golang#68995. Change-Id: I63b892ad4c313aa92f21fbd4f519a0b19d725849 Reviewed-on: https://go-review.googlesource.com/c/go/+/609355 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Prevents stack exhaustion with extremely deeply nested literal values, i.e. field values in structs. Updates golang#69138 Fixes golang#69143 Fixes CVE-2024-34155 Change-Id: I2e8e33b44105cc169d7ed1ae83fb56df0c10f1ee Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1520 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Russ Cox <rsc@google.com> (cherry picked from commit eb1b038c0d01761694e7a735ef87ac9164c6568e) Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1560 Commit-Queue: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/611175 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
…g ignore depth This change makes sure that we are properly checking the ignored field recursion depth in decIgnoreOpFor consistently. This prevents stack exhaustion when attempting to decode a message that contains an extremely deeply nested struct which is ignored. Thanks to Md Sakib Anwar of The Ohio State University (anwar.40@osu.edu) for reporting this issue. Updates golang#69139 Fixes golang#69145 Fixes CVE-2024-34156 Change-Id: Iacce06be95a5892b3064f1c40fcba2e2567862d6 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1440 Reviewed-by: Russ Cox <rsc@google.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 9f2ea73c5f2a7056b7da5d579a485a7216f4b20a) Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1581 Commit-Queue: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/611176 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Limit the size of build constraints that we will parse. This prevents a number of stack exhaustions that can be hit when parsing overly complex constraints. The imposed limits are unlikely to ever be hit in real world usage. Updates golang#69141 Fixes golang#69149 Fixes CVE-2024-34158 Change-Id: I38b614bf04caa36eefc6a4350d848588c4cef3c4 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1540 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Russ Cox <rsc@google.com> (cherry picked from commit 0c74dc9e0da0cf1e12494b514d822b5bebbc9f04) Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/1562 Commit-Queue: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/611177 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: I1f2dab5560d3214c8934074a53f7750d8d431936 Reviewed-on: https://go-review.googlesource.com/c/go/+/611196 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Commit-Queue: Gopher Robot <gobot@golang.org> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org>
…on 15 On Arch Linux with gdb version 15.1, the test for TestGdbAutotmpTypes print the following output, ---- ~/src/go/src/runtime $ go test -run=TestGdbAutotmpTypes -v === RUN TestGdbAutotmpTypes === PAUSE TestGdbAutotmpTypes === CONT TestGdbAutotmpTypes runtime-gdb_test.go:78: gdb version 15.1 runtime-gdb_test.go:570: gdb output: Loading Go Runtime support. Target 'exec' cannot support this command. Breakpoint 1 at 0x46e416: file /tmp/TestGdbAutotmpTypes750485513/001/main.go, line 8. This GDB supports auto-downloading debuginfo from the following URLs: <https://debuginfod.archlinux.org> Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. [New LWP 355373] [New LWP 355374] [New LWP 355375] [New LWP 355376] Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/TestGdbAutotmpTypes750485513/001/main.go:8 8 func main() { 9 var iface interface{} = map[string]astruct{} All types matching regular expression "astruct": File runtime: []main.astruct bucket<string,main.astruct> hash<string,main.astruct> main.astruct typedef hash<string,main.astruct> * map[string]main.astruct; typedef noalg.[8]main.astruct noalg.[8]main.astruct; noalg.map.bucket[string]main.astruct runtime-gdb_test.go:587: could not find []main.astruct; in 'info typrs astruct' output !!! FAIL exit status 1 FAIL runtime 0.273s $ ---- In the back trace for "File runtime", each output lines does not end with ";" anymore, while in test we check the string with it. While at it, print the expected string with "%q" instead of "%s" for better error message. For golang#67089 Fixes golang#69746 Change-Id: If6019ee68c0d8e495c920f98568741462c7d0fd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/598135 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit ff695ca) Reviewed-on: https://go-review.googlesource.com/c/go/+/617455 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
In Android version 11 and earlier, pidfd-related system calls are not allowed by the seccomp policy, which causes crashes due to SIGSYS signals. For golang#69065 Fixes golang#69640 Change-Id: Ib29631639a5cf221ac11b4d82390cb79436b8657 GitHub-Last-Rev: aad6b3b GitHub-Pull-Request: golang#69543 Reviewed-on: https://go-review.googlesource.com/c/go/+/614277 Auto-Submit: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit a3a05ed) Reviewed-on: https://go-review.googlesource.com/c/go/+/616077 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
I've done some more testing of the new isSending field. I'm not able to get more than 2 bits set. That said, with this change it's significantly less likely to have even 2 bits set. The idea here is to clear the bit before possibly locking the channel we are sending the value on, thus avoiding some delay and some serialization. For golang#69312 For golang#69333 Change-Id: I8b5f167f162bbcbcbf7ea47305967f349b62b0f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/617596 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Commit-Queue: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
…ture check clone(CLONE_PIDFD) was added in Linux 5.2 and pidfd_open was added in Linux 5.3. Thus our feature check for pidfd_open should be sufficient to ensure that clone(CLONE_PIDFD) works. Unfortuantely, some alternative Linux implementations may not follow this strict ordering. For example, QEMU 7.2 (Dec 2022) added pidfd_open, but clone(CLONE_PIDFD) was only added in QEMU 8.0 (Apr 2023). Debian bookworm provides QEMU 7.2 by default. For golang#68976. Fixes golang#69259. Change-Id: Ie3f3dc51f0cd76944871bf98690abf59f68fd7bf Reviewed-on: https://go-review.googlesource.com/c/go/+/592078 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 7a5fc9b) Reviewed-on: https://go-review.googlesource.com/c/go/+/612218
…ature check child Inside Google we have seen issues with QEMU user mode failing to wake a parent waitid when this child exits with SYS_EXIT. This bug appears to not affect SYS_EXIT_GROUP. It is currently unclear if this is a general QEMU or specific to Google's configuration, but SYS_EXIT and SYS_EXIT_GROUP are semantically equivalent here, so we can use the latter here in case this is a general QEMU bug. For golang#68976. For golang#69259. Change-Id: I34e51088c9a6b7493a060e2a719a3cc4a3d54aa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/617417 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 47a9935) Reviewed-on: https://go-review.googlesource.com/c/go/+/617716
…ing null terminated Fix a regression introduced in CL 572396 causing goroutine stacks not getting null terminated. This bug impacts callers that reuse the []StackRecord slice for multiple calls to GoroutineProfile. See felixge/fgprof#33 for an example of the problem. Add a test case to prevent similar regressions in the future. Use null padding instead of null termination to be consistent with other profile types and because it's less code to implement. Also fix the ThreadCreateProfile code path. Fixes golang#69258 Change-Id: I0b9414f6c694c304bc03a5682586f619e9bf0588 Reviewed-on: https://go-review.googlesource.com/c/go/+/609815 Reviewed-by: Tim King <taking@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit 49e542a) Reviewed-on: https://go-review.googlesource.com/c/go/+/621277 Reviewed-by: Cherry Mui <cherryyz@google.com>
The Ticker Stop and Reset methods don't report a value, so we don't need to track whether they are interrupting a send. This includes a test that used to fail about 2% of the time on my laptop when run under x/tools/cmd/stress. For golang#69880 Fixes golang#69882 Change-Id: Ic6d14b344594149dd3c24b37bbe4e42e83f9a9ad Reviewed-on: https://go-review.googlesource.com/c/go/+/620136 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 48849e0) Reviewed-on: https://go-review.googlesource.com/c/go/+/620137 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This change switches isSending to be an atomic.Int32 instead of an atomic.Uint8. The Int32 version is managed as a counter, which is something that we couldn't do with Uint8 without adding a new intrinsic which may not be available on all architectures. That is, instead of only being able to support 8 concurrent timer firings on the same timer because we only have 8 independent bits to set for each concurrent timer firing, we can now have 2^31-1 concurrent timer firings before running into any issues. Like the fact that each bit-set was matched with a clear, here we match increments with decrements to indicate that we're in the "sending on a channel" critical section in the timer code, so we can report the correct result back on Stop or Reset. We choose an Int32 instead of a Uint32 because it's easier to check for obviously bad values (negative values are always bad) and 2^31-1 concurrent timer firings should be enough for anyone. Previously, we avoided anything bigger than a Uint8 because we could pack it into some padding in the runtime.timer struct. But it turns out that the type that actually matters, runtime.timeTimer, is exactly 96 bytes in size. This means its in the next size class up in the 112 byte size class because of an allocation header. We thus have some free space to work with. This change increases the size of this struct from 96 bytes to 104 bytes. (I'm not sure if runtime.timer is often allocated directly, but if it is, we get lucky in the same way too. It's exactly 80 bytes in size, which means its in the 96-byte size class, leaving us with some space to work with.) Fixes golang#69978 For golang#69969. Related to golang#69880 and golang#69312 and golang#69882. Change-Id: I9fd59cb6a69365c62971d1f225490a65c58f3e77 Cq-Include-Trybots: luci.golang.try:go1.23-linux-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/621616 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 6a49f81) Reviewed-on: https://go-review.googlesource.com/c/go/+/621856 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
…in coroswitch Goroutine profiles require checking in with the profiler before any goroutine starts running. coroswitch is a place where a goroutine may start running, but where we do not check in with the profiler, which leads to crashes. Fix this by checking in with the profiler the same way execute does. For golang#69998. Fixes golang#70001. Change-Id: Idef6dd31b70a73dd1c967b56c307c7a46a26ba73 Reviewed-on: https://go-review.googlesource.com/c/go/+/622016 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 2a98a18) Reviewed-on: https://go-review.googlesource.com/c/go/+/622375 Reviewed-by: Michael Pratt <mpratt@google.com>
…s specified Currently, on Mach-O, the Go linker doesn't generate LC_UUID in internal linking mode. This causes some macOS system tools unable to track the binary, as well as in some cases the binary unable to access local network on macOS 15. This CL makes the linker start generate LC_UUID. Currently, the UUID is generated if the -B flag is specified. And we'll make it generate UUID by default in a later CL. The -B flag is currently for generating GNU build ID on ELF, which is a similar concept to Mach-O's UUID. Instead of introducing another flag, we just use the same flag and the same setting. Specifically, "-B gobuildid" will generate a UUID based on the Go build ID. Updates golang#68678. Fixes golang#69992. Cq-Include-Trybots: luci.golang.try:go1.23-darwin-amd64_14,go1.23-darwin-arm64_13 Change-Id: I90089a78ba144110bf06c1c6836daf2d737ff10a Reviewed-on: https://go-review.googlesource.com/c/go/+/618595 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ingo Oeser <nightlyone@googlemail.com> Reviewed-by: Than McIntosh <thanm@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 20ed603) Reviewed-on: https://go-review.googlesource.com/c/go/+/622595 Reviewed-by: Michael Pratt <mpratt@google.com>
…Sendfile return on BSD The BSD implementation of poll.SendFile incorrectly halted copying after succesfully writing one full chunk of data. Adjust the copy loop to match the Linux and Solaris implementations. In testing, empirically macOS appears to sometimes return EAGAIN from sendfile after successfully copying a full chunk. Add a check to all implementations to return nil after successfully copying all data if the last sendfile call returns EAGAIN. For golang#70000 For golang#70020 Change-Id: I57ba649491fc078c7330310b23e1cfd85135c8ff Reviewed-on: https://go-review.googlesource.com/c/go/+/622235 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit bd388c0) Reviewed-on: https://go-review.googlesource.com/c/go/+/622696
…dfile(2) sending the full chunk CL 622235 would fix golang#70000 while resulting in one extra sendfile(2) system call when sendfile(2) returns (>0, EAGAIN). That's also why I left sendfile_bsd.go behind, and didn't make it line up with other two implementations: sendfile_linux.go and sendfile_solaris.go. Unlike sendfile(2)'s on Linux and Solaris that always return (0, EAGAIN), sendfile(2)'s on *BSD and macOS may return (>0, EAGAIN) when using a socket marked for non-blocking I/O. In that case, the current code will try to re-call sendfile(2) immediately, which will most likely get us a (0, EAGAIN). After that, it goes to `dstFD.pd.waitWrite(dstFD.isFile)` below, which should have been done in the first place. Thus, the real problem that leads to golang#70000 is that the old code doesn't handle the special case of sendfile(2) sending the exact number of bytes the caller requested. Fixes golang#70000 Fixes golang#70020 Change-Id: I6073d6b9feb58b3d7e114ec21e4e80d9727bca66 Reviewed-on: https://go-review.googlesource.com/c/go/+/622255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Andy Pan <panjf2000@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/622697
Fix a regression introduced in CL 598515 causing runtime.MutexProfile stack traces to omit their root frames. In most cases this was merely causing the `runtime.goexit` frame to go missing. But in the case of runtime._LostContendedRuntimeLock, an empty stack trace was being produced. Add a test that catches this regression by checking for a stack trace with the `runtime.goexit` frame. Also fix a separate problem in expandFrame that could cause out-of-bounds panics when profstackdepth is set to a value below 32. There is no test for this fix because profstackdepth can't be changed at runtime right now. Fixes golang#69865 Change-Id: I1600fe62548ea84981df0916d25072c3ddf1ea1a Reviewed-on: https://go-review.googlesource.com/c/go/+/611615 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit c64ca8c) Reviewed-on: https://go-review.googlesource.com/c/go/+/621276 Reviewed-by: Cherry Mui <cherryyz@google.com>
syscall.SyscallX consumes a lot of stack space, which is a problem because they are nosplit functions. They used to use less stack space, but CL 563315, that landed in Go 1.23, increased the stack usage by a lot. This CL reduces the stack usage back to the previous level. Fixes golang#69848 Updates golang#69813 Change-Id: Iddedd28b693c66a258da687389768055c493fc2e Reviewed-on: https://go-review.googlesource.com/c/go/+/618497 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit fa7343a) Reviewed-on: https://go-review.googlesource.com/c/go/+/623516 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: I065005a4a18f801d09ad3ebc886e90a6dd1df69a Reviewed-on: https://go-review.googlesource.com/c/go/+/626137 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
… f contain closure c?" The old test relied on naming conventions. The new test uses an explicit parent pointer chain initialized when the closures are created (in the same place that the names used in the older fragile test were assigned). Fixes golang#70198. Change-Id: Ie834103c7096e4505faaff3bed1fc6e918a21211 Reviewed-on: https://go-review.googlesource.com/c/go/+/622656 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/625535 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
This stops the test from failing with a known failure mode, and creates time to look into what the next steps should be, if any. For golang#69840 Fixes golang#70239 Change-Id: I060903d256ed65c5dfcd70ae76eb361cab63186f Reviewed-on: https://go-review.googlesource.com/c/go/+/625197 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> 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> Reviewed-by: Eric Grosse <grosse@gmail.com> (cherry picked from commit bea9b91) Reviewed-on: https://go-review.googlesource.com/c/go/+/627575 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
syscall.SyscallN is implemented by runtime.syscall_syscalln, which makes sure that the variadic argument doesn't escape. There is no need to worry about the lifetime of the elements of the variadic argument, as the compiler will keep them live until the function returns. For golang#70197 Fixes golang#70202 Change-Id: I12991f0be12062eea68f2b103fa0a794c1b527eb Reviewed-on: https://go-review.googlesource.com/c/go/+/625297 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 7fff741) Reviewed-on: https://go-review.googlesource.com/c/go/+/630196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
…ing mark termination Currently it's possible for weak->strong conversions to create more GC work during mark termination. When a weak->strong conversion happens during the mark phase, we need to mark the newly-strong pointer, since it may now be the only pointer to that object. In other words, the object could be white. But queueing new white objects creates GC work, and if this happens during mark termination, we could end up violating mark termination invariants. In the parlance of the mark termination algorithm, the weak->strong conversion is a non-monotonic source of GC work, unlike the write barriers (which will eventually only see black objects). This change fixes the problem by forcing weak->strong conversions to block during mark termination. We can do this efficiently by setting a global flag before the ragged barrier that is checked at each weak->strong conversion. If the flag is set, then the conversions block. The ragged barrier ensures that all Ps have observed the flag and that any weak->strong conversions which completed before the ragged barrier have their newly-minted strong pointers visible in GC work queues if necessary. We later unset the flag and wake all the blocked goroutines during the mark termination STW. There are a few subtleties that we need to account for. For one, it's possible that a goroutine which blocked in a weak->strong conversion wakes up only to find it's mark termination time again, so we need to recheck the global flag on wake. We should also stay non-preemptible while performing the check, so that if the check *does* appear as true, it cannot switch back to false while we're actively trying to block. If it switches to false while we try to block, then we'll be stuck in the queue until the following GC. All-in-all, this CL is more complicated than I would have liked, but it's the only idea so far that is clearly correct to me at a high level. This change adds a test which is somewhat invasive as it manipulates mark termination, but hopefully that infrastructure will be useful for debugging, fixing, and regression testing mark termination whenever we do fix it. For golang#69803. Fixes golang#70323. Change-Id: Ie314e6fd357c9e2a07a9be21f217f75f7aba8c4a Reviewed-on: https://go-review.googlesource.com/c/go/+/623615 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 80d306d) Reviewed-on: https://go-review.googlesource.com/c/go/+/627615 TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
…getOrAddWeakHandle getOrAddWeakHandle is very careful about keeping its input alive across the operation, but not very careful about keeping the heap-allocated handle it creates alive. In fact, there's a window in this function where it is *only* visible via the special. Specifically, the window of time between when the handle is stored in the special and when the special actually becomes visible to the GC. (If we fail to add the special because it already exists, that case is fine. We don't even use the same handle value, but the one we obtain from the attached GC-visible special, *and* we return that value, so it remains live.) For golang#70455. Fixes golang#70469. Change-Id: Iadaff0cfb93bcaf61ba2b05be7fa0519c481de82 Reviewed-on: https://go-review.googlesource.com/c/go/+/630316 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…ows-386 The failures in golang#70288 are consistent with and strongly imply stack corruption during fault handling, and debug prints show that the Go code run during fault handling is running about 300 bytes above the bottom of the goroutine stack. That should be okay, but that implies the DLL code that called Go's handler was running near the bottom of the stack too, and maybe it called other deeper things before or after the Go handler and smashed the stack that way. stackSystem is already 4096 bytes on amd64; making it match that on 386 makes the flaky failures go away. It's a little unsatisfying not to be able to say exactly what is overflowing the stack, but the circumstantial evidence is very strong that it's Windows. For golang#70288. Fixes golang#70475. Change-Id: Ife89385873d5e5062a71629dbfee40825edefa49 Reviewed-on: https://go-review.googlesource.com/c/go/+/627375 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 7eeb0a1) Reviewed-on: https://go-review.googlesource.com/c/go/+/632196 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Veronica Silina <veronicasilina@google.com>
Fix a regression that appeared in 1.23 when it comes to the stack traces shown in the trace viewer. In 1.22 and earlier, the viewer was always showing end stack traces. In 1.23 and later the viewer started to exclusively show start stack traces. Showing only the start stack traces made it impossible to see the last stack trace produced by a goroutine. It also made it hard to understand why a goroutine went off-cpu, as one had to hunt down the next running slice of the same goroutine. Emit end stack traces in addition to start stack traces to fix the issue. Fixes golang#70592 Change-Id: Ib22ea61388c1d94cdbc99fae2d207c4dce011a59 Reviewed-on: https://go-review.googlesource.com/c/go/+/631895 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 6405e60) Reviewed-on: https://go-review.googlesource.com/c/go/+/632075 Reviewed-by: Veronica Silina <veronicasilina@google.com> Auto-Submit: Veronica Silina <veronicasilina@google.com>
Change-Id: I8d26e5231e868476949390ec900f0273c816d807 Reviewed-on: https://go-review.googlesource.com/c/go/+/633217 Reviewed-by: Veronica Silina <veronicasilina@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Flips the pkgReader.enableAlias flag to true when reading unified IR. This was disabled while resolving golang#66873. This resolves the TODO to flip it back to true. Fixes golang#70394 Fixes golang#70517 Updates golang#66873 Change-Id: Ifd52b0f9510d6bcf151de1c9a18d71ab548c14e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/604099 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit 209ed1a) Reviewed-on: https://go-review.googlesource.com/c/go/+/631855 Commit-Queue: Tim King <taking@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
…t cgocallback Currently, at a cgo callback where there is already a Go frame on the stack (i.e. C->Go->C->Go), we require that at the inner Go callback the SP is within the g0's stack bounds set by a previous callback. This is to prevent that the C code switches stack while having a Go frame on the stack, which we don't really support. But this could also happen when we cannot get accurate stack bounds, e.g. when pthread_getattr_np is not available. Since the stack bounds are just estimates based on the current SP, if there are multiple C->Go callbacks with various stack depth, it is possible that the SP of a later callback falls out of a previous call's estimate. This leads to runtime throw in a seemingly reasonable program. This CL changes it to save the old g0 stack bounds at cgocallback, update the bounds, and restore the old bounds at return. So each callback will get its own stack bounds based on the current SP, and when it returns, the outer callback has the its old stack bounds restored. Also, at a cgo callback when there is no Go frame on the stack, we currently always get new stack bounds. We do this because if we can only get estimated bounds based on the SP, and the stack depth varies a lot between two C->Go calls, the previous estimates may be off and we fall out or nearly fall out of the previous bounds. But this causes a performance problem: the pthread API to get accurate stack bounds (pthread_getattr_np) is very slow when called on the main thread. Getting the stack bounds every time significantly slows down repeated C->Go calls on the main thread. This CL fixes it by "caching" the stack bounds if they are accurate. I.e. at the second time Go calls into C, if the previous stack bounds are accurate, and the current SP is in bounds, we can be sure it is the same stack and we don't need to update the bounds. This avoids the repeated calls to pthread_getattr_np. If we cannot get the accurate bounds, we continue to update the stack bounds based on the SP, and that operation is very cheap. On a Linux/AMD64 machine with glibc: name old time/op new time/op delta CgoCallbackMainThread-8 96.4µs ± 3% 0.1µs ± 2% -99.92% (p=0.000 n=10+9) Updates golang#68285. Updates golang#68587. Fixes golang#69988. Change-Id: I3422badd5ad8ff63e1a733152d05fb7a44d5d435 Reviewed-on: https://go-review.googlesource.com/c/go/+/600296 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit 76a8409) Reviewed-on: https://go-review.googlesource.com/c/go/+/635775
…handle EOPNOTSUPP/ENOTSUP This is not a cherry pick, because the code has changed on tip. For golang#70763 Fixes golang#70789 Change-Id: If9fcfee17e86a746cf8c72293dc34f80b430f6e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/635397 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…pired certificates Updates golang#71077 Fixes golang#71104 Change-Id: I6a6a465685f3bd50a5bb35a160f87b59b74fa6af Reviewed-on: https://go-review.googlesource.com/c/go/+/639655 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/640315 Reviewed-by: Filippo Valsorda <filippo@golang.org>
…in injectglist Currently injectglist emits all the trace events before actually calling casgstatus on each goroutine. This is a problem, since tracing can observe an inconsistent state (gstatus does not match tracer's 'emitted an event' state). This change fixes the problem by having injectglist do what every other scheduler function does, and that's wrap each call to casgstatus in traceAcquire/traceRelease. For golang#70883. Fixes golang#71147. Change-Id: I857e96cec01688013597e8efc0c4c3d0b72d3a70 Reviewed-on: https://go-review.googlesource.com/c/go/+/638558 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit f025d19) Reviewed-on: https://go-review.googlesource.com/c/go/+/641378 Auto-Submit: Michael Pratt <mpratt@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Please ensure you adhere to every item in this list.
More info can be found at https://github.com/golang/go/wiki/CommitMessage
net/http: frob the quux before blarfing
"This change modifies Go to ___________"
really needed (ASCII art, table, or long link)
Fixes #1234
orUpdates #1234
(the latter if this is not a complete fix) to this comment
golang/go
you can use theowner/repo#issue_number
syntax:Fixes golang/tools#1234
Our Gerrit server & GitHub bots enforce CLA compliance instead.