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: panic if recursive type with field of error type #47636

Closed
bmizerany opened this issue Aug 11, 2021 · 3 comments
Closed

cmd/compile: panic if recursive type with field of error type #47636

bmizerany opened this issue Aug 11, 2021 · 3 comments

Comments

@bmizerany
Copy link
Contributor

@bmizerany bmizerany commented Aug 11, 2021

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

$ go version
go version go1.16.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes. I have reproduced it with go1.16.7 darwin/amd64

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

go env Output
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/bmizerany/Library/Caches/go-build"
GOENV="/Users/bmizerany/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/bmizerany/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/bmizerany/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.7"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/bmizerany/go/src/resume/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rf/6fdgwbmj2rxf1jw13q4fv7h80000gn/T/go-build1864976941=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I wrote a little program with a recursive type which also contained a field of type error, and then ran both go test and go build:

$ cat hrm.go
package hrm

type T struct {
	E error
	T T
}

What did you expect to see?

A helpful error that I made a recursive type and the location where it was detected in the source.

What did you see instead?

A panic from cmd/compile:

hrm % go build           
# hrm
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x1641d8e]

goroutine 1 [running]:
cmd/compile/internal/gc.findTypeLoop(0xc000370240, 0xc0000ca8d8, 0xc00040a040)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:202 +0xce
cmd/compile/internal/gc.findTypeLoop(0xc000400fc0, 0xc0000ca8d8, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:216 +0x2c5
cmd/compile/internal/gc.findTypeLoop(0xc000400f60, 0xc0000ca8d8, 0x11)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:202 +0x117
cmd/compile/internal/gc.reportTypeLoop(0xc000400f60)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:240 +0x76
cmd/compile/internal/gc.dowidth(0xc000400f60)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:282 +0x1105
cmd/compile/internal/gc.widstruct(0xc000400f60, 0xc000400f60, 0x0, 0x1, 0x20)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:114 +0xd3
cmd/compile/internal/gc.dowidth(0xc000400f60)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:435 +0x4cf
cmd/compile/internal/gc.widstruct(0xc000400fc0, 0xc000400fc0, 0x0, 0x1, 0x8)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:114 +0xd3
cmd/compile/internal/gc.dowidth(0xc000400fc0)
	/usr/local/go/src/cmd/compile/internal/gc/align.go:435 +0x4cf
cmd/compile/internal/gc.resumecheckwidth()
	/usr/local/go/src/cmd/compile/internal/gc/align.go:526 +0x4c
cmd/compile/internal/gc.typecheckdef(0xc000408000)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:3695 +0x8e5
cmd/compile/internal/gc.typecheck1(0xc000408000, 0x4, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:343 +0xbace
cmd/compile/internal/gc.typecheck(0xc000408000, 0x4, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:299 +0x785
cmd/compile/internal/gc.typecheck1(0xc00040e200, 0x1, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:2077 +0x4e65
cmd/compile/internal/gc.typecheck(0xc00040e200, 0x1, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:299 +0x785
cmd/compile/internal/gc.Main(0x18c5cf8)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:603 +0x2aa5
main.main()
	/usr/local/go/src/cmd/compile/main.go:52 +0xb1

NOTE: If you remove the field I error, the helpful error appears. I tried changing the type of E to interface{} and I did not get the panic, but the helpful error instead. The same goes for changing E to a concrete type such as int. I've only be able to reproduce with the error type.

@bmizerany
Copy link
Contributor Author

@bmizerany bmizerany commented Aug 11, 2021

Another reproduction with odd behavior:

package hrm

// If either of the below types commented out are uncommented, there is no
// panic and a helpful error message.
//
// type HelpfulError1 struct {
//      E int
//      T HelpfulError1
// }    
//      
// type HelpfulError2 struct {
//      E interface{}
//      T HelpfulError2
// }    
        
type Panics struct {
        E error
        T Panics
} 

Loading

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Aug 11, 2021

This is fixed on tip, maybe by CL https://go-review.googlesource.com/c/go/+/274094

Loading

@bmizerany
Copy link
Contributor Author

@bmizerany bmizerany commented Aug 11, 2021

@cuonglm I had a hunch this was a known issue. Thank you for confirming!

Loading

@cuonglm cuonglm closed this Aug 11, 2021
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
2 participants