cmd/compile: stack overflow with a recursive type

[yansal]

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

go version go1.9 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/yann/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build782515074=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

go build this program

package main

import "fmt"

type a struct {
	b
}

type b struct {
	a
}

func main() {
	fmt.Println(a{})
}

What did you expect to see?

Probably the invalid recursive type error message

What did you see instead?

cmd/compile crashes with the following stack overflow.

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0xb5d565, 0xe)
	/usr/local/go/src/runtime/panic.go:605 +0x95
runtime.newstack(0x0)
	/usr/local/go/src/runtime/stack.go:1050 +0x6e1
runtime.morestack()
	/usr/local/go/src/runtime/asm_amd64.s:415 +0x86

goroutine 1 [running]:
cmd/compile/internal/types.(*Type).Fields(0xc42038ed80, 0x0)
	/usr/local/go/src/cmd/compile/internal/types/type.go:813 +0x177 fp=0xc440382360 sp=0xc440382358 pc=0x4d7907
cmd/compile/internal/types.(*Fields).Len(...)
	/usr/local/go/src/cmd/compile/internal/types/type.go:1277
cmd/compile/internal/types.(*Type).NumFields(0xc42038ed80, 0xc42038ee40)
	/usr/local/go/src/cmd/compile/internal/types/type.go:1277 +0x2b fp=0xc440382380 sp=0xc440382360 pc=0x4d937b
cmd/compile/internal/gc.isdirectiface(0xc42038ed80, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/subr.go:2045 +0xbd fp=0xc4403823a8 sp=0xc440382380 pc=0xa3157d
cmd/compile/internal/gc.isdirectiface(0xc42038ee40, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/subr.go:2045 +0x101 fp=0xc4403823d0 sp=0xc4403823a8 pc=0xa315c1

[ALTree]

Reproduced at tip, but also with go1.8.4, so it's not a recent regression.

go1.7.5 prints invalid recursive type b.

[ianlancetaylor]

gccgo prints

foo.go:5:6: error: invalid recursive type ‘a’
 type a struct {
      ^
foo.go:9:6: error: invalid recursive type ‘b’
 type b struct {
      ^

[odeke-em]

I've binary search narrowed the cause of this regression to 295307a CL https://go-review.googlesource.com/#/c/38139/ /cc @philhofer and @dr2chase

However, I can't directly see how that change causes the type breakage tests to fail.

You can verify the analysis by visiting
https://github.com/golang/go/commits/release-branch.go1.9?after=5476967b1a3d29fef4061999c00cadbec19ac0e3+419&path%5B%5D=src&path%5B%5D=cmd&path%5B%5D=compile
Before it:
commit 6917553 works
Itself and after it:
commit 91d08e3 produces the crash
/cc @mdempsky

[dr2chase]

A possibility is that the plain call enables more aggressive escape analysis, which can make a stack (much?) larger than it was before.

[mdempsky]

The crash is because isdirectiface is infinitely recursing on the broken types. A simple

if t.Broke() { return false }

check fixes it.

This is another symptom of the general problem that we trudge forward into the backend even when we've found typechecking errors. (Edit: Filed #22909 to track this.)

[mdempsky]

(I'm working on a CL now, since it's trivial to fix.)

[gopherbot]

Change https://golang.org/cl/80301 mentions this issue: cmd/compile: fix infinite recursion in isdirectiface