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

Comments

@jdef
Copy link

@jdef 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

@bradfitz bradfitz commented Jan 11, 2018

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

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 11, 2018

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

@bradfitz bradfitz added NeedsFix and removed WaitingForInfo labels Jan 11, 2018
@bradfitz bradfitz added this to the Go1.11 milestone Jan 11, 2018
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 11, 2018

/cc @crawshaw

@sabin-rapan
Copy link
Contributor

@sabin-rapan sabin-rapan commented Jan 21, 2018

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

@sabin-rapan sabin-rapan commented Jan 28, 2018

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

@wenjingLi729 wenjingLi729 commented Nov 27, 2019

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

@rickyzhang82

This comment was marked as disruptive content.

@ianlancetaylor

This comment has been hidden.

@rickyzhang82
Copy link

@rickyzhang82 rickyzhang82 commented Jul 21, 2020

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

@ianlancetaylor ianlancetaylor commented Jul 21, 2020

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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.