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

Jump to bottom

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

Closed
hengwu0 opened this issue Jul 16, 2018 · 6 comments
Closed

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

hengwu0 opened this issue Jul 16, 2018 · 6 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@hengwu0
Copy link
Contributor

hengwu0 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 tests: run tests failed with lots of cases in buildmode=shared cmd/link: run tests failed with lots of cases in buildmode=shared Jul 16, 2018
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 16, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 16, 2018
@ianlancetaylor
Copy link
Contributor

CC @mwhudson

@mwhudson
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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
@ianlancetaylor
cmd/internal/buildid: close ELF file after reading note
274fde9 
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
Copy link

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
@ianlancetaylor
cmd/go: fix handling of vet.cfg with buggyInstall
f17220c 
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
@seankhliao
Copy link
Member

Obsoleted by #47788

@golang golang locked and limited conversation to collaborators Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@mwhudson @ianlancetaylor @gopherbot @seankhliao @hengwu0