cmd/compile: memory corruption from `//go:notinheap` interface method wrappers

[mdempsky]

If T is a //go:notinheap type, then *T is treated like uintptr rather than pointer-shaped. One consequence of this is that the interface method wrappers for T need to use **T instead of *T.

However, reflectdata.methodWrapper doesn't handle this correctly. For example, this program panics, whereas it succeeds if you remove the //go:notinheap directive: https://play.golang.org/p/p7TiaXlyJzX

Discovered while reimplementing wrapper generation for unified IR.

[gopherbot]

Change https://golang.org/cl/330569 mentions this issue: [dev.typeparams] cmd/compile: generate wrappers within unified IR

[mknyszek]

@mdempsky This looks like it could be fixed, but I haven't been following the unified IR work so I'm not sure if that's been enabled by default. Please close if so. Thanks!

[ianlancetaylor]

The program in the initial comment now causes a compiler crash:

# command-line-arguments
esc
.   CALL tc(1) # <autogenerated>:1:0
.   .   DOTPTR main.M tc(1) # <autogenerated>:1:0
.   .   .   NAME-main..this ld(1) Class:PPARAM Offset:0 OnStack Used PTR-**A tc(1) # <autogenerated>:1:0
<autogenerated>:1: .this.M undefined (type **A has no field or method M)

This only happens when usin the go:notinheap directive, so this doesn't seem critical. The go:notinheap directive isn't even documented. So changing milestone to 1.19.

[cherrymui]

Maybe we can disallow putting notinheap types in interfaces. Do we need notinheap types in interfaces?

[mdempsky]

Do we need notinheap types in interfaces?

I just tested hacking unified IR to reject converting notinheap types to interface, and the only error building the standard library is this code in netpoll.go for getting the *_type for *pollDesc:

netpoll.go:     pdEface any    = (*pollDesc)(nil)
netpoll.go:     pdType  *_type = efaceOf(&pdEface)._type

It's possible end users put cgo C.foo and *C.foo types into interfaces too, though cgo types don't have methods.

[cherrymui]

Thanks. These two don't need methods. So maybe we can make it that notinheap type doesn't satisfy any interface methods. So (only) empty interface is fine.

[randall77]

I like the idea of forbidding methods on notinheap types.
Or just that their methods don't satisfy otherwise corresponding interface methods?

[cherrymui]

It probably suffices to just make it not satisfy interface methods. We can still have methods on them, and calling them directly is still fine. (We currently have methods on notinheap types, e.g. mheap).

[mdempsky]

I'm a bit worried about subtle desyncs between static and dynamic interface satisfiability.

How do folks feel about instead disallowing conversion of T and *T to any interface type (including empty interface), when T is notinheap and has methods?

The alternative is to implicitly treat all methods on a notinheap type as nointerface. I think that should work fine, but currently nointerface is only used for GOEXPERIMENT=fieldtrack, so it's a bit less exercised than other compiler code paths.

[cherrymui]

The alternative is to implicitly treat all methods on a notinheap type as nointerface

Yeah, this is what I thought. It is determined statically. The methods are not in the type descriptor's method table, so it cannot be put into an interface with method dynamically (and also statically).