cmd/compile: nil pointer dereference panic in types2.operand.assignableTo

[mvdan]

Luckily it happened on an open source codebase; below are repro steps.

$ go version
go version devel go1.18-c2397905e0 Sat Nov 13 03:33:55 2021 +0000 linux/amd64
$ mkdir test
$ cd test
$ go mod init test
go: creating new go.mod: module test
$ go get github.com/libp2p/go-eventbus@ae6fa05fd0f393cada3060234e43d70ce8297dd0
[...]
$ go build github.com/libp2p/go-eventbus
# github.com/libp2p/go-eventbus
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xb76e31]

goroutine 1 [running]:
cmd/compile/internal/types2.(*Checker).handleBailout(0xc000380820, 0xc000179648)
	/home/mvdan/tip/src/cmd/compile/internal/types2/check.go:273 +0x8b
panic({0xc9ea00, 0x12fad70})
	/home/mvdan/tip/src/runtime/panic.go:838 +0x207
cmd/compile/internal/types2.(*operand).assignableTo(0xc000780000, 0xc000380820, {0xe854b8?, 0xc000515f10?}, 0x0)
	/home/mvdan/tip/src/cmd/compile/internal/types2/operand.go:319 +0x971
cmd/compile/internal/types2.(*Checker).comparison(0xc000380820, 0xc000780000, 0xc000780040, 0x7)
	/home/mvdan/tip/src/cmd/compile/internal/types2/expr.go:774 +0x67
cmd/compile/internal/types2.(*Checker).binary(0x0?, 0xc000780000, {0xe86778?, 0xc0000fb840}, {0xe86748?, 0xc0000fc6e0}, {0xe86838?, 0xc00049b170}, 0x7)
	/home/mvdan/tip/src/cmd/compile/internal/types2/expr.go:1028 +0x8d6
cmd/compile/internal/types2.(*Checker).exprInternal(0xc000380820, 0xc000780000, {0xe86778?, 0xc0000fb840}, {0x0?, 0x0?})
	/home/mvdan/tip/src/cmd/compile/internal/types2/expr.go:1576 +0x14e9
cmd/compile/internal/types2.(*Checker).rawExpr(0xc000380820, 0xc000780000, {0xe86778?, 0xc0000fb840?}, {0x0?, 0x0?}, 0x0)
	/home/mvdan/tip/src/cmd/compile/internal/types2/expr.go:1119 +0x1a5
cmd/compile/internal/types2.(*Checker).expr(0x0?, 0x0?, {0xe86778?, 0xc0000fb840?})
	/home/mvdan/tip/src/cmd/compile/internal/types2/expr.go:1663 +0x35
cmd/compile/internal/types2.(*Checker).stmt(0xc000380820, 0x0, {0xe865c8?, 0xc0000ec960?})
	/home/mvdan/tip/src/cmd/compile/internal/types2/stmt.go:552 +0x1105
cmd/compile/internal/types2.(*Checker).stmtList(0xce7a80?, 0x0, {0xc0004b2300?, 0xc000647450?, 0xc000647408?})
	/home/mvdan/tip/src/cmd/compile/internal/types2/stmt.go:124 +0xc9
cmd/compile/internal/types2.(*Checker).funcBody(0xc000380820, 0xc0006af140, {0xc0000ee6d8?, 0xc0000fc6c0?}, 0xc0006aca40, 0xc0000fb800, {0x0, 0x0})
	/home/mvdan/tip/src/cmd/compile/internal/types2/stmt.go:45 +0x3fb
cmd/compile/internal/types2.(*Checker).funcDecl.func1()
	/home/mvdan/tip/src/cmd/compile/internal/types2/decl.go:814 +0x45
cmd/compile/internal/types2.(*Checker).processDelayed(0xc000380820, 0x0)
	/home/mvdan/tip/src/cmd/compile/internal/types2/check.go:356 +0x44
cmd/compile/internal/types2.(*Checker).checkFiles(0xc000380820, {0xc0005149c0, 0x2, 0x2})
	/home/mvdan/tip/src/cmd/compile/internal/types2/check.go:306 +0x172
cmd/compile/internal/types2.(*Checker).Files(...)
	/home/mvdan/tip/src/cmd/compile/internal/types2/check.go:278
cmd/compile/internal/types2.(*Config).Check(0xc9c640?, {0x7ffebd68780a?, 0xd0fb95?}, {0xc0005149c0, 0x2, 0x2}, 0xc00017d780?)
	/home/mvdan/tip/src/cmd/compile/internal/types2/api.go:422 +0x70
cmd/compile/internal/noder.checkFiles({0xc0000729c0, 0x2, 0x7f720f6552a0?})
	/home/mvdan/tip/src/cmd/compile/internal/noder/irgen.go:65 +0x49c
cmd/compile/internal/noder.check2({0xc0000729c0, 0x2, 0x2})
	/home/mvdan/tip/src/cmd/compile/internal/noder/irgen.go:78 +0x46
cmd/compile/internal/noder.LoadPackage({0xc00001e220, 0x2, 0x0?})
	/home/mvdan/tip/src/cmd/compile/internal/noder/noder.go:90 +0x335
cmd/compile/internal/gc.Main(0xd43fa8)
	/home/mvdan/tip/src/cmd/compile/internal/gc/main.go:191 +0xb13
main.main()
	/home/mvdan/tip/src/cmd/compile/main.go:55 +0xdd

cc @griesemer @findleyr @ALTree

[findleyr]

Thanks for the report. Looking.

[mvdan]

By the way, what's with the bits in the stack trace like 0x0? - I haven't seen that kind of "pointer" before.

[findleyr]

Minimal-ish repro:

func _() {
	var x *interface{}
	var y interface{}
	_ = x == y
}

We're simply missing a check for nil reason. Will send a fix.

By the way, what's with the bits in the stack trace like 0x0? - I haven't seen that kind of "pointer" before.

@mvdan I'm not sure, those particular pointers should not be nil. I'm curious too.

[griesemer]

cc @randall77 re: the question above.

[randall77]

That's from https://go-review.googlesource.com/c/go/+/352057

[gopherbot]

Change https://golang.org/cl/364034 mentions this issue: cmd/compile/internal/types2: add a check for nil reason in assignableTo