Skip to content
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: document that KeepAlive doesn't have anything to do with unsafe.Pointer safety rules #47562

mdempsky opened this issue Aug 5, 2021 · 1 comment


Copy link

@mdempsky mdempsky commented Aug 5, 2021

There's nothing in the runtime.KeepAlive or unsafe.Pointer documentation to suggest they interact, but I've seen experienced Go engineers mistakenly interpret that runtime.KeepAlive can be used as a quick-fix for working around misuse of unsafe.Pointer.

This often happens to work today, but it's not guaranteed to be safe. In particular, misuse of unsafe.Pointer can lead to objects being allocated on the stack, which can result in unintended program behavior due to memory corruption:

We don't normally document what things aren't used for, but this seems like a subtle enough point to call out, IMO.

Copy link

@gopherbot gopherbot commented Aug 5, 2021

Change mentions this issue: runtime: warn that KeepAlive is not an unsafe.Pointer workaround


@gopherbot gopherbot closed this in fd45e26 Aug 5, 2021
@dmitshur dmitshur added this to the Go1.17 milestone Aug 5, 2021
steeve added a commit to znly/go that referenced this issue Aug 19, 2021
Even experienced users occasionally mistake that runtime.KeepAlive can
be used as a workaround for following the unsafe.Pointer safety rules,
but it cannot. Add an explicit warning to this effect to dissuade
users from trying to use it as such.

Fixes golang#47562.

Change-Id: I842e33a3e1c080933c6b1bd1b6318448adbf495c
Trust: Matthew Dempsky <>
Reviewed-by: Ian Lance Taylor <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants