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

plugin: type switches fail with reflect-created types #24399

Open
mdempsky opened this issue Mar 15, 2018 · 2 comments
Open

plugin: type switches fail with reflect-created types #24399

mdempsky opened this issue Mar 15, 2018 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@mdempsky
Copy link
Member

cmd/compile generates type hashes using MD5, but package reflect uses FNV-1 when dynamically constructing anonymous types. This causes type switches (which first search on type hash) to misbehave when using package plugin:

$ go build -buildmode=plugin w.go
$ go run x.go
FAIL; got *[8675309]int

$ cat x.go
package main

import (
	"plugin"
	"reflect"
)

func main() {
	v := reflect.New(reflect.ArrayOf(8675309, reflect.TypeOf(0))).Interface()

	p, err := plugin.Open("w.so")
	if err != nil {
		panic(err)
	}
	f, err := p.Lookup("F")
	if err != nil {
		panic(err)
	}
	f.(func(interface{}))(v)
}

$ cat w.go
package main

import "fmt"

func F(x interface{}) {
	switch x.(type) {
	case *[8675309]int:
		fmt.Println("ok")
	default:
		fmt.Printf("FAIL; got %T\n", x)
	}
}

Notably, the failure goes away if the array type is constructed after the plugin.Open call, or if there's an explicit *[8675309]int type in x.go.

/cc @ianlancetaylor @mwhudson @crawshaw

@mdempsky
Copy link
Member Author

Actually, on top of the type hashes not matching, there are also duplicate runtime types. The latter alone causes type assertions to also fail.

I suspect both (duplicate type descriptors + mismatched type hashes) need to be fixed for type switches to work correctly though.

@andybons
Copy link
Member

@mdempsky can you assign the appropriate label(s) and milestone?

@mdempsky mdempsky added this to the Go1.11 milestone Mar 15, 2018
@mdempsky mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 15, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 27, 2018
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants