commit 0d3b472d24240812746f1094f8eb1f4944c75929 [browse]
Author: Sergey Matveev
Date: 2024-12-04 13:31:30 +03:00

Autogenerated TLS-related strings

go install golang.org/x/tools/cmd/stringer@latest
cd src/crypto/tls ; go generate

commit cc2e90b2a1fcf4a8b54b009290b92d0d2458ca93 [browse]
Author: Sergey Matveev
Date: 2023-02-02 00:19:57 +03:00

GOST X.509 and TLS 1.3 support via GoGOST

commit 194de8fbfaf4c3ed54e1a3c1b14fc67a830b8d95 [browse]
Author: Gopher Robot
Date: 2024-12-03 17:22:32 Z

[release-branch.go1.23] go1.23.4

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>

commit 5164a865e3de723f07976edac234c4d6a814128e [browse]
Author: Felix Geisendörfer
Date: 2024-11-26 09:10:22 +01:00

[release-branch.go1.23] cmd/trace: also show end stack traces

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 #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 6405e60ca6be798c1f8c1d0365fd63b89b524df5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/632075
Reviewed-by: Veronica Silina <veronicasilina@google.com>
Auto-Submit: Veronica Silina <veronicasilina@google.com>

commit 25f042daecda1058baa25b213f1692d22ff5fb73 [browse]
Author: Russ Cox
Date: 2024-11-12 23:23:12 +01:00

[release-branch.go1.23] runtime: reserve 4kB for system stack on windows-386

The failures in #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 #70288.
Fixes #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 7eeb0a188eb644486da9f77bae0375d91433d0bf)
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>