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

cmd/link: -gcflags=-race causes panic #42396

Closed
cuonglm opened this issue Nov 5, 2020 · 8 comments
Closed

cmd/link: -gcflags=-race causes panic #42396

cuonglm opened this issue Nov 5, 2020 · 8 comments
Assignees
Milestone

Comments

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Nov 5, 2020

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

$ go version
go version devel +3ef8562c9c Thu Nov 5 02:48:05 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env

What did you do?

$ cd "$(go1.15.3 env GOROOT)/src/strings"
$ go1.15.3 test -gcflags=-race .

What did you expect to see?

Friendly error messages like go1.14.x does:

# strings.test
type..eq.[6]string: relocation target runtime.racefuncenter not defined
type..eq.[6]string: relocation target runtime.raceread not defined
type..eq.[6]string: relocation target runtime.racefuncexit not defined
type..eq.[2]string: relocation target runtime.racefuncenter not defined
type..eq.[2]string: relocation target runtime.raceread not defined
type..eq.[2]string: relocation target runtime.racefuncexit not defined
type..eq.[3]string: relocation target runtime.racefuncenter not defined
type..eq.[3]string: relocation target runtime.raceread not defined
type..eq.[3]string: relocation target runtime.racefuncexit not defined
type..eq.[4]string: relocation target runtime.racefuncenter not defined
type..eq.[4]string: relocation target runtime.raceread not defined
type..eq.[4]string: relocation target runtime.racefuncexit not defined
type..eq.[10]string: relocation target runtime.racefuncenter not defined
type..eq.[10]string: relocation target runtime.raceread not defined
type..eq.[10]string: relocation target runtime.racefuncexit not defined
type..eq.[8]string: relocation target runtime.racefuncenter not defined
type..eq.[8]string: relocation target runtime.raceread not defined
type..eq.[8]string: relocation target runtime.racefuncexit not defined
strings.(*Builder).String: relocation target runtime.racefuncenter not defined
strings.(*Builder).String: relocation target runtime.raceread not defined
strings.(*Builder).String: relocation target runtime.racefuncexit not defined
/home/cuonglm/sdk/go1.14.10/pkg/tool/linux_amd64/link: too many errors
FAIL	strings [build failed]
FAIL

What did you see instead?

Panic on go1.15.x and tip:

# strings.test
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x51dbbb]

goroutine 1 [running]:
cmd/link/internal/loader.(*Loader).FuncInfo(0xc00061c000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/usr/local/go/src/cmd/link/internal/loader/loader.go:1900 +0x9b
cmd/link/internal/ld.(*stkChk).check(0xc000138e78, 0xc000138d08, 0x1, 0x0)
	/usr/local/go/src/cmd/link/internal/ld/lib.go:2359 +0x130
cmd/link/internal/ld.(*stkChk).check(0xc000138e78, 0xc000138e60, 0x0, 0x0)
	/usr/local/go/src/cmd/link/internal/ld/lib.go:2418 +0x585
cmd/link/internal/ld.(*Link).dostkcheck(0xc000115880)
	/usr/local/go/src/cmd/link/internal/ld/lib.go:2319 +0x2bc
cmd/link/internal/ld.Main(0x86f840, 0x20, 0x20, 0x1, 0x7, 0x10, 0x0, 0x0, 0x6da8bf, 0x1b, ...)
	/usr/local/go/src/cmd/link/internal/ld/main.go:254 +0xe65
main.main()
	/usr/local/go/src/cmd/link/main.go:68 +0x1dc
FAIL	strings [build failed]
FAIL
@mvdan
Copy link
Member

@mvdan mvdan commented Nov 5, 2020

Out of curiosity, why do you use -gcflags=-race instead of just -race?

Loading

@thanm thanm self-assigned this Nov 5, 2020
@thanm thanm added this to the Go1.16 milestone Nov 5, 2020
@thanm
Copy link
Contributor

@thanm thanm commented Nov 5, 2020

I can take a look at this.

Loading

@cuonglm
Copy link
Member Author

@cuonglm cuonglm commented Nov 5, 2020

Out of curiosity, why do you use -gcflags=-race instead of just -race?

Actually, what I did is -gcflags=-l -race, then I want to remove -gcflags=-l, but mis-typing enter :)

Loading

@bcmills bcmills changed the title cmd/go: -gcflags=-race causes panic cmd/link: -gcflags=-race causes panic Nov 5, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 5, 2020

Change https://golang.org/cl/267881 mentions this issue: cmd/link: report error if builtin referenced but not defined

Loading

@gopherbot gopherbot closed this in 8e5778e Nov 5, 2020
@thanm
Copy link
Contributor

@thanm thanm commented Nov 5, 2020

Just FYI, with the fix I submitted to the linker, we no longer get the panic. The error message is slightly different from before however. Instead of "relocation target runtime.racefuncexit not defined" it will be an error of the form "reference to undefined builtin 'runtime.racefuncexit' from package ". Hope that is ok.

Loading

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Dec 9, 2020

@katiehockman and I ran into an error which I think might be caused by CL 267881. Specifically, we're trying to merge master into the dev.fuzz branch in CL 275448. The failure we're seeing is https://storage.googleapis.com/go-build-log/cffd0112/linux-amd64_018f19d1.log.

  • In misc/cgo/testshared, the TestTestInstalledShared test is failing.
  • TestMain copies a number of packages into a temporary GOROOT and installs with go install -buildmode=shared runtime sync/atomic. That writes pkg/linux_amd64_dynlink/libruntime,sync-atomic.so.
  • TestTestInstalledShared runs go test -linkshared sync/atomic, which fails with:
reference to undefined builtin "runtime.morestack_noctxt" from package "crypto/sha256"
  • In this CL, crypto/sha256 is imported indirectly by the test main generated by go test. So the presence of that package isn't surprising.
  • I've verified runtime.morestack_noctxt is present in pkg/linux_amd64_dynlink/libruntime,sync-atomic.so.

@thanm Any idea why this is happening? If it's helpful, I can try to make a more minimal test case in a new issue.

Loading

@thanm
Copy link
Contributor

@thanm thanm commented Dec 9, 2020

This looks like a slightly different problem from the original bug, I think it might make sense to file another issue. The CL in question is mainly there to convert a linker panic into a regular link error, whereas in this case it looks as though it should be possible for the link to succeed. I can pull your CL and try taking a closer look at it.

Loading

@thanm
Copy link
Contributor

@thanm thanm commented Dec 10, 2020

New issue filed with smaller repro: #43107

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants