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: Panic decoding json into shared type #21386
Comments
CC @crawshaw |
Great bug report. Thanks. Looks like the plugin name prefix is not being used for namedata symbols, leading to a collision between the two independent types:
Should be an easy fix, let me give it a go. |
I think the namedata symbol was a red herring, something else is causing the reflect package to get the wrong *rtype. A simplified test case: plugin1.go
plugin2.go
Load plugin1, then plugin2, and call UnexportedNameReuse(). |
The problem here is the pkgpath value inside the type.plugin1.sameNameReusedInPlugins symbol. In both the plugin1 and plugin2 types it is "main", which means the runtime typeOff logic declares them identical types and starts always picking the type from the earlier module. This is easy to fix. The pkgpath is set to "main" by the compiler, because cmd/go is passing "-p main" when compiling the package. If it left it off, or passed the correct value when building the plugin, the two types then have useful pkgpath values and the error is fixed. |
Change https://golang.org/cl/60910 mentions this issue: |
@crawshaw Thanks for the fix. go/src/encoding/json/decode.go Line 175 in 048c9cf
I'm happy to submit a pull request for this if you think it would be a good change - i.e. changing the logic to check the type of recovered panic and if it's a string (rather than error) then create new error. |
@alhails oddly, I saw a different error message to you:
This has all the information I need in it, so I'm happy the way it is. I don't know why you see something different. Is this a recent change? Mind syncing and seeing if your error is the same? |
go version go1.9rc2 linux/amd64
When multiple plugins contain the same type, this leads to errors decoding JSON into that type
Here's my simple example reproducing this behaviour.
Build the plugins using -buildmode=plugin.
I can send the full buildable project if required.
main.go
plugin1.go
plugin2.go
What did you expect to see?
Expected the decoding to work successfully with no error
What did you see instead?
The standard library reports the following error...
This error actually results from a failure to recover from the original panic - so the original error details are hidden.
This happens here since the panic is raised with a string rather than an Error...
go/src/encoding/json/decode.go
Line 175 in 048c9cf
After hacking some changes here, I discovered the original error as ...
reflect.Set: value of type *main.orgUnitName is not assignable to type *main.orgUnitName
The text was updated successfully, but these errors were encountered: