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.

Sign up for GitHub

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/compile: internal error autotmp_3 (type *int) recorded as live on entry, p.Pc=0 #15091

Closed
gyuho opened this issue Apr 4, 2016 · 8 comments
Closed

cmd/compile: internal error autotmp_3 (type *int) recorded as live on entry, p.Pc=0 #15091

gyuho opened this issue Apr 4, 2016 · 8 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@gyuho
Copy link
Contributor

gyuho commented Apr 4, 2016

This was first reported here russross/blackfriday#251, but it looks like a Go compiler issue.

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

go version devel +59fc42b Fri Apr 1 22:23:13 2016 +0000 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/gyuho/go"
GORACE=""
GOROOT="/home/gyuho/go-master/go"
GOTOOLDIR="/home/gyuho/go-master/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build999228004=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?

I just run go build -race to reproduce:

package sample

type Html struct {
    headerIDs map[string]int
}

func (options *Html) header(id string) string {
    for count, found := options.headerIDs[id]; found; count, found = options.headerIDs[id] {
        _ = count
    }
    return ""
}
What did you expect to see?

No error message.

What did you see instead?
./sample.go:7: internal error: (*Html).header autotmp_3 (type *int) recorded as live on entry, p.Pc=0

Thank you all!
@bradfitz bradfitz added this to the Go1.7 milestone Apr 4, 2016
@bradfitz
Copy link
Contributor

bradfitz commented Apr 4, 2016

/cc @randall77 @brtzsnr @josharian

@josharian
Copy link
Contributor

git bisect implicates e99dd52

/cc @dr2chase

@josharian
Copy link
Contributor

Although I don't really see how

@josharian
Copy link
Contributor

Oh. Because I was using a script with git bisect, and that version fails make.bash. Sigh. Trying again with a better script...

@josharian
Copy link
Contributor

Actually, that revision might be the actual culprit. From the description: "Add convert op for proper liveness in presence of uintptr to/from unsafe.Pointer conversions." And I forgot that this gets triggered via the race detector, which plays fast and loose with types internally.

@josharian josharian mentioned this issue Apr 8, 2016
Closed
@dr2chase
Copy link
Contributor

dr2chase commented Apr 8, 2016

Unclear whether race detector is inserting bad code or if this is a fumbled conversion.
autotmp_3 appears after "walk", target of an assignment:

.   .   .   .   .   AS u(1) l(8) tc(1)
.   .   .   .   .   .   NAME-sample.autotmp_3 u(1) a(true) l(8) x(0+0) class(PAUTO) esc(N) tc(1) used(true) PTR64-*int
.   .   .   .   .   .   INDREG-SP a(true) l(8) x(32+0) tc(1) runtime.val·1 PTR64-*int

Race detector inserts what looks like a use before initialization, though we could have botched the conversions, too:

.   .   .   CALLFUNC u(100) l(8) tc(1)
.   .   .   .   NAME-runtime.raceread u(1) a(true) x(0+0) class(PFUNC) tc(1) used(true) FUNC-func(uintptr)
.   .   .   CALLFUNC-list
.   .   .   .   AS u(2) l(8) tc(1)
.   .   .   .   .   INDREG-SP a(true) l(8) x(0+0) tc(1) uintptr
.   .   .   .   .   CONVNOP u(2) l(8) tc(1) uintptr
.   .   .   .   .   .   CONVNOP u(2) l(8) tc(1) TUNSAFEPTR-unsafe.Pointer
.   .   .   .   .   .   .   ADDR u(2) l(8) tc(1) PTR64-*int
.   .   .   .   .   .   .   .   IND u(2) l(8) tc(1) addrtaken int
.   .   .   .   .   .   .   .   .   NAME-sample.autotmp_3 u(1) a(true) l(8) x(0+0) class(PAUTO) esc(N) tc(1) used(true) PTR64-*int

For reasons not 100% clear, this ends up with autotmp_3 treated as if it were an argument to the function, which ultimately fails because of course it isn't.

Any insights into what the race detector is doing here would be welcome, I am going to look both at that and at the convert op code.

@gopherbot
Copy link

CL https://golang.org/cl/21771 mentions this issue.

@dr2chase dr2chase self-assigned this Apr 8, 2016
@gyuho
Copy link
Contributor Author

gyuho commented Apr 8, 2016

Awesome. Confirmed that it's fixed. Thanks all!

@gyuho gyuho mentioned this issue Apr 8, 2016
Closed
@dr2chase dr2chase mentioned this issue Jun 10, 2016
Closed
@golang golang locked and limited conversation to collaborators Apr 9, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
5 participants
@bradfitz @josharian @dr2chase @gyuho @gopherbot