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: using coverpkg when testing results in plugin version mismatch #23410

Open
jdef opened this issue Jan 11, 2018 · 10 comments
Open

plugin: using coverpkg when testing results in plugin version mismatch #23410

jdef opened this issue Jan 11, 2018 · 10 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@jdef
Copy link

jdef commented Jan 11, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.9.2

Does this issue reproduce with the latest release?

yes - 1.9.2 is the latest, stable release

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vagrant/pluginbugs"
GORACE=""
GOROOT="/usr/local/go-1.9.2"
GOTOOLDIR="/usr/local/go-1.9.2/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build917652042=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

https://github.com/jdef/plugins1/blob/master/README.md

What did you expect to see?

  • all tests pass successfully

What did you see instead?

  • the go test invocation using -coverpkg fails with "plugin was built with a different version of package..." message
@bradfitz
Copy link
Contributor

Please try go1.10beta1 or go1.10beta2, which should be out later today.

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jan 11, 2018
@bradfitz
Copy link
Contributor

Actually, I can reproduce with Go tip (~Go 1.10 beta2).

@bradfitz bradfitz added NeedsFix The path to resolution is known, but the work has not been done. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jan 11, 2018
@bradfitz bradfitz added this to the Go1.11 milestone Jan 11, 2018
@bradfitz
Copy link
Contributor

/cc @crawshaw

@sabin-rapan
Copy link
Contributor

Hello,

I started investigating this issue. Found where the panic is issued from and managed to print the plugin link hash. Can't seem to print the runtime hash though. Any tips/pointers?
Also, can I get this issue assigned to me?

@sabin-rapan
Copy link
Contributor

After further investigations, I have found that this issue is related somewhat to #17928 and #17832.

The -coverpkg flag modifies the package foo and rebuilds it, hence the different version error when opening the plugin.

Someone with more expertise needs to chime in on this. Ping @crawshaw

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 27, 2018
@wenjingLi729
Copy link

I have also encountered this problem. Are there any solutions yet?

@rickyzhang82

This comment has been minimized.

@ianlancetaylor

This comment has been minimized.

@rickyzhang82
Copy link

The test case was created by @jdef in 2018. It was done professionally from community. I gave him a thumb up for that.

But there is no response from the Golang team for 2 years! People pretend the problem doesn't exist because it may be not in line with the interest of their company. Is this an open source project still driven by a community or a private one dedicated for ONE commercial company?

I don't see the intention of generating the hash for Golang plugin at link time and verifying the hash at run time when loading it from the main process. If you want to prevent dependency version mismatch between the main process and the plugin, you should leave it to the programmers to decide. Not Go compiler. Because Go compiler has no idea about the semantic nor the contract of the dependencies. Instead of solving any practical problem, the hash itself has been a trouble maker for years.

The plugin in Go runtime is being implemented without any proper documentation. There is NO Go runtime specification that I can find online nor any open discussion of what plugin should be expected to behave. One guy from Golang team patch it until he thinks it is necessary. Then the behavior changes all in sudden. This is not acceptable for any programming language.

In addition, missing the unload plugin is another problem I want to chime in. I have never seen a program invoke dlopen to load a dynamic library without dlclose to unload it. An excuse of causing race condition when unloading it is lame. Don't you think this feature is incomplete? You open the door without closing it.

Please start to write a specification of Golang runtime or at least write a plugin specification. This development style by far handicaps Golang to be a mature language.

@ianlancetaylor
Copy link
Contributor

Is this an open source project still driven by a community or a private one dedicated for ONE commercial company?

It's an open source project.

Patches welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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

6 participants