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

Jump to bottom

cmd/compile: 'internal compiler error: initplan arraylit' during bootstrapping #33373

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

cmd/compile: 'internal compiler error: initplan arraylit' during bootstrapping #33373

bcmills opened this issue Jul 30, 2019 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.14

Comments

@bcmills
Copy link
Contributor

bcmills commented Jul 30, 2019 •
edited

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 30, 2019
@bcmills bcmills added this to the Go1.14 milestone Jul 30, 2019
@mdempsky
Copy link
Member

mdempsky commented Jul 30, 2019 •
edited

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
Copy link
Member

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
Copy link
Member

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

@aclements
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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

@ianlancetaylor
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Aug 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
5 participants
@mdempsky @aclements @ianlancetaylor @bcmills @gopherbot