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

cmd/link: run tests failed with lots of cases in buildmode=shared #26400

Open
wu-heng opened this Issue Jul 16, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@wu-heng

wu-heng commented Jul 16, 2018

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

go version go1.10.3 linux/amd64

Does this issue reproduce with the latest release?

yes

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

Linux jim-PC 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jim/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jim/go"
GORACE=""
GOROOT="/home/jim/golang/go"
GOTMPDIR=""
GOTOOLDIR="/home/jim/golang/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
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"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build891088383=/tmp/go-build -gno-record-gcc-switches"

What did you do?

1、download gz package: go1.10.3.linux-amd64.tar.gz
2、untar and add bin/ to $PATH,set GOROOT
3、shell# go install -buildmode=shared runtime sync/atomic
4、shell# go test -short -linkshared std

What did you expect to see?

all tests pass except runtime and sync/atomic。

What did you see instead?

unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x49b6f5]

goroutine 82 [running]:
runtime.throw(0x7fbf9cbf4d1e, 0x5)
/home/jim/golang/go/src/runtime/panic.go:616 +0x83 fp=0xc420089880 sp=0xc420089860 pc=0x7fbf9cbb49e3
runtime.sigpanic()
/home/jim/golang/go/src/runtime/signal_unix.go:395 +0x215 fp=0xc4200898d0 sp=0xc420089880 pc=0x7fbf9cbce7e5
internal/testlog.Open(0x5a579e, 0x15)
/home/jim/golang/go/src/internal/testlog/log.go:60 +0x95 fp=0xc420089908 sp=0xc4200898d0 pc=0x49b6f5
os.OpenFile(0x5a579e, 0x15, 0x0, 0x0, 0x200, 0x0, 0x0)
/home/jim/golang/go/src/os/file.go:268 +0x37 fp=0xc420089950 sp=0xc420089908 pc=0x4b6157
os.Open(0x5a579e, 0x15, 0x200, 0xc4200899e0, 0x599067)
/home/jim/golang/go/src/os/file.go:250 +0x48 fp=0xc420089998 sp=0xc420089950 pc=0x4b6068
io/ioutil.ReadFile(0x5a579e, 0x15, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/jim/golang/go/src/io/ioutil/ioutil.go:53 +0x54 fp=0xc4200899f0 sp=0xc420089998 pc=0x53cb94
archive/tar.TestWriter.func2(0xc4200d31d0)
/home/jim/golang/go/src/archive/tar/writer_test.go:514 +0x1060 fp=0xc420089fa8 sp=0xc4200899f0 pc=0x59a0e0
testing.tRunner(0xc4200d31d0, 0xc4200951e0)
/home/jim/golang/go/src/testing/testing.go:777 +0xda fp=0xc420089fd0 sp=0xc420089fa8 pc=0x508b8a
runtime.goexit()
/home/jim/golang/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc420089fd8 sp=0xc420089fd0 pc=0x7fbf9cbec391
created by testing.(*T).Run
/home/jim/golang/go/src/testing/testing.go:824 +0x2f9

goroutine 1 [chan receive]:
testing.(*T).Run(0xc4201354a0, 0x5a38ca, 0xa, 0x827d58, 0x4a6a01)
/home/jim/golang/go/src/testing/testing.go:825 +0x31a
testing.runTests.func1(0xc4200d2000)
/home/jim/golang/go/src/testing/testing.go:1063 +0x66
testing.tRunner(0xc4200d2000, 0xc420087df8)
/home/jim/golang/go/src/testing/testing.go:777 +0xda
testing.runTests(0xc42000c1e0, 0x8a7f80, 0x25, 0x25, 0x7fbf9cb95589)
/home/jim/golang/go/src/testing/testing.go:1061 +0x2f3
testing.(*M).Run(0xc4200ce000, 0x0)
/home/jim/golang/go/src/testing/testing.go:978 +0x180
main.main()
_testmain.go:120 +0x184

goroutine 72 [chan receive]:
testing.(*T).Run(0xc4200d31d0, 0x5a57a7, 0xc, 0xc4200951e0, 0x101)
/home/jim/golang/go/src/testing/testing.go:825 +0x31a
archive/tar.TestWriter(0xc4201354a0)
/home/jim/golang/go/src/archive/tar/writer_test.go:475 +0x239f
testing.tRunner(0xc4201354a0, 0x827d58)
/home/jim/golang/go/src/testing/testing.go:777 +0xda
created by testing.(*T).Run
/home/jim/golang/go/src/testing/testing.go:824 +0x2f9
FAIL archive/tar 0.069s
unexpected fault address 0x0

FAILED cases:archive/zip 、 bufio、bytes、compress/bzip2、compress/flate、compress/zlib、crypto/tls、encoding/json、go/printer、html/template、io、math/big 、、、、、、、、

They can be all test passed with go1.9.7.linux-amd64 in the same env!!!

@ianlancetaylor ianlancetaylor changed the title from tests: run tests failed with lots of cases in buildmode=shared to cmd/link: run tests failed with lots of cases in buildmode=shared Jul 16, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 16, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 16, 2018

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented Jul 16, 2018

Certainly something is fairly broken here :( It all seems totally erratic though, quite a few things seem to fail differently under gdb than when run directly. The one test that I tried that segfaulted under gdb was trying to write memory past the end of the heap:

   0x00007ffff7af603d <+205>:	vpbroadcastb %xmm0,%ymm1
=> 0x00007ffff7af6042 <+210>:	vmovdqu (%rdi),%ymm2
   0x00007ffff7af6046 <+214>:	vpcmpeqb %ymm1,%ymm2,%ymm3

%rdi is only 15 bytes before the end of the heap here. But I also see failures to allocate absurd amounts of memory, strings not comparing equal, it's all a mess. It would probably make sense to bisect to see when things started breaking.

I'm not going to have time to look at this for a week or so at best unfortunately.

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented Jul 16, 2018

Oh and something else is broken with go tip:

(master)mwhudson@ringil:/opt/opensource/go$ go test -linkshared bufio
readELFNote failed: open /opt/opensource/go/pkg/linux_amd64_dynlink/libruntime,sync-atomic.so: too many open files
@gopherbot

This comment has been minimized.

gopherbot commented Jul 16, 2018

Change https://golang.org/cl/124235 mentions this issue: cmd/internal/buildid: close ELF file after reading note

gopherbot pushed a commit that referenced this issue Jul 16, 2018

cmd/internal/buildid: close ELF file after reading note
Updates #26400

Change-Id: I1747d1f1018521cdfa4b3ed13412a944829967cf
Reviewed-on: https://go-review.googlesource.com/124235
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Jul 17, 2018

Change https://golang.org/cl/124275 mentions this issue: cmd/go: fix handling of vet.cfg with buggyInstall

gopherbot pushed a commit that referenced this issue Jul 17, 2018

cmd/go: fix handling of vet.cfg with buggyInstall
The vet action assumes that a.Deps[0] is the compilation action for
which vet information should be generated. However, when using
-linkshared, the action graph is built with a ModeBuggyInstall action
to install the shared library built from the compilation action.
Adjust the set up of the vet action accordingly. Also don't clean up
the working directory after completing the buggy install.

Updates #26400

Change-Id: Ia51f9f6b8cde5614a6f2e41b6207478951547770
Reviewed-on: https://go-review.googlesource.com/124275
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

@ianlancetaylor ianlancetaylor modified the milestones: Go1.12, Unplanned Dec 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment