go: reflect: duplicate reflect.Type values under dynamic linking

Please answer these questions before submitting your issue. Thanks!

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

go version go1.8rc2 linux/amd64

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

GOARCH=“amd64” GOBIN=“” GOEXE=“” GOHOSTARCH=“amd64” GOHOSTOS=“linux” GOOS=“linux” GOPATH=“/home/fsenart/projects” GORACE=“” GOROOT=“/home/fsenart/tools/go1.8rc2” GOTOOLDIR=“/home/fsenart/tools/go1.8rc2/pkg/tool/linux_amd64” GCCGO=“gccgo” CC=“gcc” GOGCCFLAGS=“-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build840231100=/tmp/go-build -gno-record-gcc-switches” CXX=“g++” CGO_ENABLED=“1” PKG_CONFIG=“pkg-config” CGO_CFLAGS=“-g -O2” CGO_CPPFLAGS=“” CGO_CXXFLAGS=“-g -O2” CGO_FFLAGS=“-g -O2” CGO_LDFLAGS=“-g -O2”

What did you do?

If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best.

// main.go

package main

import "plugin"

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

	f.(func())()
}

// plugin.go

package main

import "C"
import "net/http"

func F() {
	_, err := http.Get("https://amazon.com")
	if err != nil {
		panic(err)
	}

	_, err = http.Get("https://google.com")
	if err != nil {
		panic(err)
	}
}

test: build
	@./main

build: clean
	@go build -buildmode=plugin -o plugin.so plugin.go
	@go build -o main main.go

clean:
	@rm -rf main

What did you expect to see?

I don’t expect any panic to happen.

What did you see instead?

A panic happens when requesting https://google.com while all works as expected when requesting https://amazon.com.

panic: Get https://google.com: remote error: tls: bad record MAC

goroutine 1 [running]:
plugin/unnamed-7da7c3830d2c48526e010430dd8f9f30a6c7f139.F()
	/home/fsenart/projects/src/issues/issue_badmac/plugin.go:14 +0xa7
main.main()
	/home/fsenart/projects/src/issues/issue_badmac/main.go:15 +0xb6
Makefile:2: recipe for target 'test' failed
make: *** [test] Error 2

Observations

The issue is here since go1.8beta1
The issue happens only when using plugins.
The issue is different from #18584.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 23 (21 by maintainers)

Commits related to this issue

runtime: reorder modules so main.main comes first Modules appear in the moduledata linked list in the order they are loaded by the dynamic loader, with one exception: the firstmoduledata itself the m... — committed to golang/go by crawshaw 7 years ago

Most upvoted comments

This is probably a reflect bug of some sort meaning a message is being encoded incorrectly.

While it’s a nice short test case (thanks!) it’s tricky to pull apart because the “bad record MAC” is an error coming back from the server. I’m going to see if I can get some of the cyrpto/tls unit tests running inside a plugin and hope those narrow it down.

If they don’t, does anyone have a TLS server designed for debugging? (A TLS-aware equivalent of tcpdump?)

crawshaw on Jan 23, 2017

I had forgotten about that bug. Presumably the fix for #18252 wasn’t enough (which has been my working assumption so far, that there’s a reflect/type-info bug). I’ll dig around.

crawshaw on Jan 24, 2017

The same error occurs with -buildmode=shared, which gives us some (not exactly scrutable) unit test failures.

$ go test -linkshared -short crypto/tls
--- FAIL: TestClientResumption (0.02s)
	handshake_client_test.go:687: DifferentCipherSuite: handshake failed: local error: tls: bad record MAC
--- FAIL: TestVersion (0.01s)
	handshake_server_test.go:340: handshake failed: local error: tls: bad record MAC
--- FAIL: TestSCTHandshake (0.01s)
	handshake_server_test.go:390: handshake failed: local error: tls: bad record MAC
--- FAIL: TestHandshakeClientECDHERSAChaCha20 (0.00s)
	handshake_client_test.go:396: TLSv12-ECDHE-RSA-CHACHA20-POLY1305 #2: mismatch on read: got:16030300251000002120459a0798b78ac5dc1220f0798323cb75f8ce32eb80fbdeb886eaf25de1b57f541403030001011603030020a879516ad07f72e38cc4ec2a6a947bd25db2acce314e1101365e995f9ef0f643 want:160303002510000021202fe57da347cd62431528daac5fbb290730fff684afc4cfc2ed90995f58cb3b7414030300010116030300209d2fa6b72156ad38a831200b2edc3f8a3464de810ed3a5b1c1fc0518d93e7735
--- FAIL: TestHandshakClientSCTs (0.00s)
	handshake_client_test.go:396: TLSv12-SCT #2: mismatch on read: got:16030300251000002120459a0798b78ac5dc1220f0798323cb75f8ce32eb80fbdeb886eaf25de1b57f54140303000101160303002098378699d1c39a3dd65fd0e3575bfd63e7101d88cd3e47f79aa9ccdeda303546 want:160303002510000021202fe57da347cd62431528daac5fbb290730fff684afc4cfc2ed90995f58cb3b7414030300010116030300207a58e133d4ceca57efeab99df24decce864be9c2b564dd0f32f066654274d859
...

After many more similar failures it locks up. Building with -c and sending it a SIGQUIT show it stuck in a way that suggests one end of the client/server has locked up. EDIT: I’m omitting the stack dump but it’s available if anyone wants it.

I suspect going after the unit test failures will be easier than the lockup, so I’ll spend some time today trying to simplify one of them.

cc @mwhudson as this now affects shared libraries. Would be nice if we had a -linkshared builder to have caught this earlier.

crawshaw on Jan 24, 2017

I believe the only bug remaining here is #18820, which has been split out.

There also needs to be better testing, which I split out as #18814.

As this issue ranged across several problems, and I believe everything left is split out into those two, I’m going to close this issue. @fsenart, please follow #18820 for a resolution to your original issue.

crawshaw on Jan 30, 2017

go test -linkshared seems to be pretty broken right now (sadface) but doing things by hand suggests that go test -linkshared crypto/tls is still broken with that CL (but encoding/asn1 is indeed fixed).

mwhudson on Jan 25, 2017