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

cmd/compile: new escape analysis implementation doesn't heap-allocate pointer #33662

Closed
dsnet opened this issue Aug 15, 2019 · 3 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker Soon This needs to be done soon. (regressions, serious bugs, outages)
Milestone

Comments

@dsnet
Copy link
Member

dsnet commented Aug 15, 2019

Apache Beam has a function as follows:

func LoadFunction(ptr uintptr, t reflect.Type) interface{} {
	v := reflect.New(t).Elem()
	*(*uintptr)(unsafe.Pointer(v.Addr().Pointer())) = (uintptr)(unsafe.Pointer(&ptr))
	return v.Interface()
}

When compiled on Go1.12 with -gcflags=-m, we see:

functions.go:43: &ptr escapes to heap

When compiled on Go1.13 with -gcflags=-m, the fact that &ptr escapes is no longer true. The effect of this change is a subtle memory corruption where since &ptr now points to the heap, rather than a copy of the value on the stack.

Git bisect reports that the issue is due to CL/170448, which seems to suggest that this breakage is intentional. The fix the Beam code is relatively straight forward by manually allocating ptr on the heap.

I'm filing an issue to confirm that this is an expected regression.

\cc @mdempsky @dr2chase

@andybons andybons added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Soon This needs to be done soon. (regressions, serious bugs, outages) labels Aug 15, 2019
@andybons andybons added this to the Go1.13 milestone Aug 15, 2019
@cherrymui
Copy link
Member

I think this was intentional. The assignment is done as integer assignment, not pointer assignment, so it does not form an escape edge. The old escape analysis was a bit conservative on this.

@mdempsky
Copy link
Member

Yeah, the change was intentional. That LoadFunction code is not using unsafe.Pointer safely according to https://golang.org/pkg/unsafe/#Pointer

Easiest fix would be:

*(**uintptr)(unsafe.Pointer(v.Addr().Pointer())) = &ptr

@andybons
Copy link
Member

Closing as this is confirmed intentional behavior. Thanks, @mdempsky and @cherrymui!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker Soon This needs to be done soon. (regressions, serious bugs, outages)
Projects
None yet
Development

No branches or pull requests

5 participants