-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
runtime: "traceback did not unwind completely" #62326
Comments
#62182 tracks a similar failure mode on |
(attn @aclements @prattmic) |
Thanks for the bisect! Reproduced with: git clone https://github.com/prysmaticlabs/gohashtree
cd gohashtree
GOTOOLCHAIN=go1.21.0 go test The crash happens in the very first test run,
We appear to reach this via |
On entry to
Looks reasonable.
However, That leads to two question:
|
Oops, not sure how I missed it, but it clearly does write SP: https://github.com/prysmaticlabs/gohashtree/blob/aafd8b3ca202c8010581affc92aee966cc01ef79/hash_amd64.s#L2055 So, while the current rules around this are a little unfortunate, the unwinder is actually correctly failing. At the moment, we have no way to identify just parts of functions where SP has been adjusted in a way we don't understand (possibly we should), which means the unwinder assumes it can't know anything about the frame size anywhere in the function. One way to fix this in gohashtree would be to move the "shani" code to its own NOSPLIT function called only from Now I'm really curious why the old unwinder didn't fail in the same way. |
Ah hah. The old unwinder ignored SPWRITE on the innermost frame. The new unwinder rearranged these conditions slightly so it doesn't immediately panic if it sees SPWRITE on the innermost frame, but it does leave We should recreate the old behavior. I think the old condition was brittle, though (e.g., that's definitely the wrong behavior if you're unwinding from a trap that landed in an SPWRITE function). I'll have to figure out what the right condition is. |
FWIW, also happens with github.com/minio/sha256-simd@v0.1.1 (the problematic assembly runs only on AVX512-enabled CPUs). Old version, I know, so I fixed this with dependency bump, but still. |
Change https://go.dev/cl/525835 mentions this issue: |
@gopherbot , please backport to Go 1.21. This causes the runtime to crash when an assembly function that modifies SP grows the stack or is preempted for GC. This should be pretty rare, but the crash is difficult to work around. |
Backport issue(s) opened: #62464 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Confirming that this resolves prysmaticlabs/gohashtree#13 |
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
The tests in https://github.com/prysmaticlabs/gohashtree fail with a
Steps to reproduce:
What did you expect to see?
Tests pass
Culprit
After git bisect the commit that broke the package is https://go-review.googlesource.com/c/go/+/458218
which creates the undwinder.
The text was updated successfully, but these errors were encountered: