plugin: using coverpkg when testing results in plugin version mismatch

[jdef]

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]

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

[bradfitz]

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

[bradfitz]

/cc @crawshaw

[sabin-rapan]

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]

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

[wenjingLi729]

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

[rickyzhang82]

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]

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.