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: 'internal compiler error: initplan arraylit' during bootstrapping #33373

Closed
bcmills opened this issue Jul 30, 2019 · 8 comments
Closed
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 30, 2019

Seen on the darwin-amd64-10_11 builder in https://build.golang.org/log/671c132f280f43cdb546ef72c83902b21b324923:

Building Go cmd/dist using /Users/gopher/go1.4.
Building Go toolchain1 using /Users/gopher/go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.
# vendor/golang.org/x/text/unicode/norm
src/vendor/golang.org/x/text/unicode/norm/tables11.0.0.go:2923:5: internal compiler error: initplan arraylit: invalid index 560:39213

goroutine 1 [running]:
runtime/debug.Stack(0x1bdb040, 0xc000082000, 0x0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/debug/stack.go:24 +0x9d
cmd/compile/internal/gc.Fatalf(0x1a4a2e5, 0x23, 0xc000ca1380, 0x1, 0x1)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/subr.go:188 +0x291
cmd/compile/internal/gc.(*InitSchedule).initplan(0xc001ac1a70, 0xc000cb9980)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/sinit.go:1058 +0x36a
cmd/compile/internal/gc.(*InitSchedule).staticassign(0xc001ac1a70, 0xc000cadb30, 0xc000cb9980, 0xc0003dc000)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/sinit.go:239 +0xae2
cmd/compile/internal/gc.(*InitSchedule).tryStaticInit(0xc001ac1a70, 0xc000e2d480, 0x1836700)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/sinit.go:64 +0xd8
cmd/compile/internal/gc.(*InitSchedule).staticInit(0xc001ac1a70, 0xc000e2d480)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/sinit.go:40 +0x39
cmd/compile/internal/gc.(*InitOrder).flushReady(0xc001b60440, 0xc000ca1690)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/initorder.go:162 +0x1b1
cmd/compile/internal/gc.initOrder(0xc000706000, 0xde, 0x120, 0xc001b4e828, 0x8, 0x8)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/initorder.go:88 +0x1d1
cmd/compile/internal/gc.fninit(0xc000706000, 0xde, 0x120)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/init.go:34 +0x5d
cmd/compile/internal/gc.Main(0x1a59120)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/internal/gc/main.go:692 +0x394a
main.main()
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/cmd/compile/main.go:51 +0xac

go tool dist: FAILED: /private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

The call in question was added in CL 151599 for #23781 (released in Go 1.12).

CC @griesemer @mdempsky @randall77

@bcmills bcmills added this to the Go1.14 milestone Jul 30, 2019
@mdempsky

This comment has been minimized.

Copy link
Member

@mdempsky mdempsky commented Jul 30, 2019

This seems like a memory corruption issue to me.

That compiler frontend code in question here (gc/sinit.go) is pretty deterministic, and the Fatalf message suggests an AST structure that shouldn't be possible (an OKEY node with its LHS also being an OKEY node), and certainly not during compiling valid code (e.g., the standard library).

I'd suspect either the runtime or some heap-pointer-handling code in the compiler backend is at fault here.

/cc @aclements

@mdempsky

This comment has been minimized.

Copy link
Member

@mdempsky mdempsky commented Jul 30, 2019

The builder failure was testing https://go-review.googlesource.com/c/go/+/186926. Could be related (CL touches the GC), but could also be a red herring.

/cc @mknyszek for FYI

@mdempsky mdempsky modified the milestones: Go1.14, Go1.13 Jul 30, 2019
@mdempsky

This comment has been minimized.

Copy link
Member

@mdempsky mdempsky commented Jul 30, 2019

Bumping to release-blocker for Go 1.13, at least until we've investigated and have a better understanding of the issue.

@aclements

This comment has been minimized.

Copy link
Member

@aclements aclements commented Jul 31, 2019

I agree that this appears to be a corruption issue and not a compiler issue. We've never had an "initplan arraylit" failure before on the dashboard (though this Fatalf has only existed since last November), and I agree with @mdempsky 's assessment that this is an OKEY on the LHS of an OKEY, which doesn't make sense and would never have passed type checking. There's also no parallelism at this point, so it can't be a race under fninit (though perhaps an earlier race could have corrupted the AST).

Curiously, the invalid node it's printing out is a real node in tables11.0.0.go: 0x230: 0x992d on line 3005. Unfortunately, we can't tell what OKEY node is pointing to that node from the error.

Given that this appears very unlikely to be a compiler bug and has only been observed once, I'm going to downgrade it from a release blocker.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 2, 2019

I suppose this could theoretically be a race condition.

In any case bumping to 1.14.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.13, Go1.14 Aug 2, 2019
@mdempsky

This comment has been minimized.

Copy link
Member

@mdempsky mdempsky commented Aug 2, 2019

@ianlancetaylor Do you mean a race between cmd/compile and background GC threads?

Like @aclements mentions, I believe cmd/compile is single-threaded during sinit.go. It was previously multi-threaded during parsing and AST translation (noder.go)... but if we constructed a bad AST, we should have tripped up during typecheck (which is also single-threaded).

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 2, 2019

Sorry, I missed that the compiler was single-threaded at that point.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 2, 2019

In that case I think that has to be a fluke. Closing. We can reopen if we see it again.

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