Skip to content

runtime: traceback stuck in runtime.systemstack [1.19 backport] #56636

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.

Sign up for GitHub

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

Jump to bottom
Closed
gopherbot opened this issue Nov 7, 2022 · 2 comments
Closed

runtime: traceback stuck in runtime.systemstack [1.19 backport] #56636

gopherbot opened this issue Nov 7, 2022 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone
Go1.19.4

Comments

@gopherbot
Copy link
Contributor

@cherrymui requested issue #55851 to be considered for backport to the next 1.19 minor release.

@gopherbot please backport this to previous releases. This may cause runtime crashes. Thanks.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Nov 7, 2022
@gopherbot gopherbot mentioned this issue Nov 7, 2022
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 7, 2022
@gopherbot gopherbot added this to the Go1.19.4 milestone Nov 7, 2022
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/448516 mentions this issue: [release-branch.go1.19] runtime: don't jump stack if at entry of systemstack

@mknyszek mknyszek added the CherryPickApproved Used during the release process for point releases label Nov 9, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Nov 9, 2022
gopherbot pushed a commit that referenced this issue Nov 9, 2022
@cherrymui @mknyszek
[release-branch.go1.19] runtime: don't jump stack if at entry of syst…
ec65108 
…emstack

The traceback code has special "jump stack" logic, to trace back
stack switches through systemstack. If we're at the entry of
systemstack, the stack switch hasn't happened, so don't jump to
user stack.

The jump stack logic is only used if we're on the g0 stack. It can
happen that we're at the entry of a recursive systemstack call on
the g0 stack. In we jump stack here, there will be two problems:
1. There are frames between entering the g0 stack and this
   recursive systemstack call. Those frames will be lost.
2. Worse, we switched frame.sp but frame.fp calculation will use
   the entry SP delta (0), which will be wrong, which in turn
   leads wrong frame.lr and things will go off.

For now, don't jump stack if we're at entry of systemstack (SP
delta is 0).

Using a per-PC SPWRITE marker may be a better fix. If we haven't
written the SP, we haven't switched the stack so we can just
unwind like a normal function.

Updates #55851.
Fixes #56636.

Change-Id: I2b624c8c086b235b34d9c7d3cebd4a37264f00f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/437299
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 500bc6b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/448516
@gopherbot
Copy link
Contributor Author

Closed by merging ec65108 to release-branch.go1.19.

andrew-d pushed a commit to tailscale/go that referenced this issue Dec 7, 2022
@cherrymui @andrew-d
[release-branch.go1.19] runtime: don't jump stack if at entry of syst…
2e0f5b6 
…emstack

The traceback code has special "jump stack" logic, to trace back
stack switches through systemstack. If we're at the entry of
systemstack, the stack switch hasn't happened, so don't jump to
user stack.

The jump stack logic is only used if we're on the g0 stack. It can
happen that we're at the entry of a recursive systemstack call on
the g0 stack. In we jump stack here, there will be two problems:
1. There are frames between entering the g0 stack and this
   recursive systemstack call. Those frames will be lost.
2. Worse, we switched frame.sp but frame.fp calculation will use
   the entry SP delta (0), which will be wrong, which in turn
   leads wrong frame.lr and things will go off.

For now, don't jump stack if we're at entry of systemstack (SP
delta is 0).

Using a per-PC SPWRITE marker may be a better fix. If we haven't
written the SP, we haven't switched the stack so we can just
unwind like a normal function.

Updates golang#55851.
Fixes golang#56636.

Change-Id: I2b624c8c086b235b34d9c7d3cebd4a37264f00f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/437299
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 500bc6b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/448516
@golang golang locked and limited conversation to collaborators Nov 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
Go1.19.4
Development

No branches or pull requests
2 participants
@mknyszek @gopherbot