-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: TLS slot index over 64 and crash [1.20 backport] #60535
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
Comments
@qmuntal Thanks for requesting this backport. The next step here is to create a cherry-pick CL following the https://go.dev/wiki/MinorReleases#making-cherry-pick-cls process. CL 486816 backports to release-branch.go1.20 mostly cleanly, except not the change in the src/runtime/sys_windows_386.s file. I think it's because CL 454675 only happened in Go 1.21. Should the cherry-pick CL to 1.20 leave out the change to sys_windows_386.s, or do you suggest a different path for this backport? Thanks. |
I've submitted the cherry-pick leaving the |
Change https://go.dev/cl/504475 mentions this issue: |
CL is ready, it just needs to be submitted. I don't have permissions to submit to a release branch. |
@qmuntal Thanks. I left minor comments on its commit message, and will submit it after they're resolved. |
Closed by merging 6b45fb7 to release-branch.go1.20. |
…en TLS slots are full Note: This CL is cherry-picked from CL 486816 omitting the changes in sys_windows_386.s, which don't apply to go1.20 release branch because windows/386 started using the TEB TLS slot in go1.21 (CL 454675). The Go runtime allocates the TLS slot in the TEB TLS slots instead of using the TEB arbitrary pointer. See CL 431775 for more context. The problem is that the TEB TLS slots array only has capacity for 64 indices, allocating more requires some complex logic that we don't support yet. Although the Go runtime only allocates one index, a Go DLL can be loaded in a process with more than 64 TLS slots allocated, in which case it abort. This CL avoids aborting by falling back to the older behavior, that is to use the TEB arbitrary pointer. Fixes #60535 Updates #59213 Change-Id: I39c73286fe2da95aa9c5ec5657ee0979ecbec533 Reviewed-on: https://go-review.googlesource.com/c/go/+/486816 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Run-TryBot: Quim Muntal <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Reviewed-by: Alex Brainman <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 715d53c) Reviewed-on: https://go-review.googlesource.com/c/go/+/504475 Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
@qmuntal requested issue #59213 to be considered for backport to the next 1.20 minor release.
The text was updated successfully, but these errors were encountered: