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/compile: go build panics when 'len' keyword was unintentionally shadowed #27973

Closed
harikb opened this issue Oct 2, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@harikb
Copy link

commented Oct 2, 2018

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

go version go1.11.1 darwin/amd64
(Also occured on go version go1.11 darwin/amd64)

Does this issue reproduce with the latest release?

Yes

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

Mac OS X 10.12.6

What did you do?

go build

Exact steps are here (fix is not pushed yet, so that code will still break)
https://play.golang.org/p/Xt3wlYYucAZ . (Not Go code, but a shell session)

What did you expect to see?

Apparently, as per go 1.10.3 (from Slack), the error message should have been

[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> go version
go version go1.10.3 darwin/amd64
[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> go build
# github.com/harikb/pghash/lib/pghash
../../lib/pghash/pghash.go:60:18: cannot call non-function len (type uint32)
[I] meta@keynsham ~/P/G/s/g/h/p/c/pghash> 

What did you see instead?

$ go build
# github.com/harikb/pghash/lib/pghash
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x177c96e]

goroutine 1 [running]:
cmd/compile/internal/gc.typecheck1(0xc00037c180, 0x2, 0xc00037b680)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1270 +0x3ece
cmd/compile/internal/gc.typecheck(0xc00037c180, 0x2, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheck1(0xc00037c100, 0x2, 0x10)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1711 +0x4781
cmd/compile/internal/gc.typecheck1(0xc00037c100, 0x2, 0xc000378f00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1229 +0x39d9
cmd/compile/internal/gc.typecheck(0xc00037c100, 0x2, 0xc000378f00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheckas(0xc00037c000)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:3336 +0xa4
cmd/compile/internal/gc.typecheck1(0xc00037c000, 0x1, 0xc00037bf00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1985 +0x332a
cmd/compile/internal/gc.typecheck(0xc00037c000, 0x1, 0xc00037bf00)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheckslice(0xc00037c200, 0x10, 0x10, 0x1)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x50
cmd/compile/internal/gc.Main(0x18c1300)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:518 +0x2059
main.main()
	/usr/local/go/src/cmd/compile/main.go:51 +0x96
@harikb

This comment has been minimized.

Copy link
Author

commented Oct 2, 2018

After applying the following fix (patch file) to the code, the build went through just fine
Fixes to main.go are irrelevant to the problem.

https://play.golang.org/p/JW0Wwtr3Aja

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 2, 2018

This appears to be fixed at tip.

@odeke-em, @griesemer, is there something to backport to Go 1.11?

@harikb

This comment has been minimized.

Copy link
Author

commented Oct 2, 2018

Sorry I did not include go env output. Here it is

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hbhaskar/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hbhaskar/code"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-L/usr/local/lib"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/s_/mh6lcqcs33z1dp8gytlf05pc0000gn/T/go-build648323542=/tmp/go-build -gno-record-gcc-switches -fno-common"

@bradfitz bradfitz added this to the Go1.11.2 milestone Oct 2, 2018

@bradfitz bradfitz changed the title go build panics when 'len' keyword was unintentionally shadowed cmd/compile: go build panics when 'len' keyword was unintentionally shadowed Oct 2, 2018

@ALTree

This comment has been minimized.

Copy link
Member

commented Oct 2, 2018

This has already been selected for a 1.11 backport: #27399, but for some reason it wasn't included in 1.11.1, it was moved (with a few others) on a future 1.11.2

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 2, 2018

Bummer. Not sure why that wasn't included in Go 1.11.1.

Will close this one as a duplicate of that.

/cc @andybons @katiehockman @dmitshur

@bradfitz bradfitz closed this Oct 2, 2018

@katiehockman

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2018

I'm checking my terminal logs, and I can see that releasebot moved issue #27399 over from Go 1.11.1 to Go 1.11.2 yesterday when I ran releasebot -mode=release go1.11.1. I'll investigate why that happened, since it looks like that issue was both closed and tagged by the time that the command was run.

@katiehockman

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2018

The reason it wasn't added to 1.11.1 is because a cherrypick CL was not merged for #27399, thus the issue was still open when the release occurred. Open issues like that one are moved to the next minor release (in this case, 1.11.2). If we want to get this into 1.11.2 then someone should create the cherry pick CL and merge it into the release1.11 branch, thus closing #27399.

See https://github.com/golang/go/wiki/MinorReleases for more details.

@ALTree

This comment has been minimized.

Copy link
Member

commented Oct 3, 2018

Sigh, I tried to send the cherry-pick CL -so we don't forget again-, but apparently only the change author (and I assume the go devs) can do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.