0.12-rc1 crashes on Terraform apply when specifying input plan

[tuckerwales]

Terraform Version

Terraform v0.12.0-rc1
+ provider.aws v2.9.0

Crash Output

  meta.count-boundary (EachMode fixup) - *terraform.Npanic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1921737]

goroutine 699 [running]:
github.com/hashicorp/terraform/terraform.(*NodeApplyableResourceInstance).EvalTree(0xc000c02d50, 0x276a220, 0xc000c02d50)
	/opt/gopath/src/github.com/hashicorp/terraform/terraform/node_resource_apply_instance.go:111 +0x2a7
github.com/hashicorp/terraform/terraform.(*Graph).walk.func1(0x276a220, 0xc000c02d50, 0x0, 0x0, 0x0)
	/opt/gopath/src/github.com/hashicorp/terraform/terraform/graph.go:78 +0xd30
github.com/hashicorp/terraform/dag.(*Walker).walkVertex(0xc0003e4180, 0x276a220, 0xc000c02d50, 0xc000d924c0)
	/opt/gopath/src/github.com/hashicorp/terraform/dag/walk.go:392 +0x353
created by github.com/hashicorp/terraform/dag.(*Walker).Update
	/opt/gopath/src/github.com/hashicorp/terraform/dag/walk.go:314 +0xa9b
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1921737]

goroutine 699 [running]:
github.com/hashicorp/terraform/terraform.(*NodeApplyableResourceInstance).EvalTree(0xc000c02d50, 0x276a220, 0xc000c02d50)
	/opt/gopath/src/github.com/hashicorp/terraform/terraform/node_resource_apply_instance.go:111 +0x2a7
github.com/hashicorp/terraform/terraform.(*Graph).walk.func1(0x276a220, 0xc000c02d50, 0x0, 0x0, 0x0)
	/opt/gopath/src/github.com/hashicorp/terraform/terraform/graph.go:78 +0xd30
github.com/hashicorp/terraform/dag.(*Walker).walkVertex(0xc0003e4180, 0x276a220, 0xc000c02d50, 0xc000d924c0)
	/opt/gopath/src/github.com/hashicorp/terraform/dag/walk.go:392 +0x353
created by github.com/hashicorp/terraform/dag.(*Walker).Update
	/opt/gopath/src/github.com/hashicorp/terraform/dag/walk.go:314 +0xa9b

Expected Behavior

For the plan to be applied.

Actual Behavior

The Terraform CLI crashes

Steps to Reproduce

terraform plan -out=terraform.plan
terraform apply terraform.plan

[jbardin]

Hi @tuckerwales,

Thanks for filing the issue! Wold it be possible to provide some configuration that demonstrates how you arrived at this error?

[tuckerwales]

@jbardin no problem,

What kind of config are you looking for? We're using modules to import quite a lot of config so it's probably infeasible to include all of that.

[jbardin]

It would be nice if we could reduce it to a manageable size, but I understand that's not simple when there's a lot of configuration to work with. We may still be able to get enough info without it. Would it be possible to provide the log output with TF_LOG=trace?

Was this an apply from scratch, or was this after modifying an existing state?

Does the exact same operation work if you apply directly without saving the plan?

Thanks!

[apparentlymart]

Given the location of this panic...

terraform/terraform/node_resource_apply_instance.go

Lines 110 to 118 in 00cc578

	// Eval info is different depending on what kind of resource this is
	switch n.Config.Mode {
	case addrs.ManagedResourceMode:
	return n.evalTreeManagedResource(addr, stateId, stateDeps)
	case addrs.DataResourceMode:
	return n.evalTreeDataResource(addr, stateId, stateDeps)
	default:
	panic(fmt.Errorf("unsupported resource mode %s", n.Config.Mode))
	}

It looks like we somehow ended up with a graph node with no configuration attached. Because plan and apply both use the same configuration by definition (the configuration is in the plan file), that is unexpected, and so I think as @jbardin said at least a more complete trace log could be helpful to see why that might be. Any additional context would be very helpful too.

[tuckerwales]

Oddly enough, I just tried to get you more information and it seems to have started working. I rm -rf'ed my .terraform folder earlier and ran terraform init again so maybe that's related.

@jbardin this was an apply after modifying state. And yes, it worked when applying - that's how I got around the problem originally.

Sorry I can't offer any more information or logs.

[apparentlymart]

Thanks for following up, @tuckerwales!

Since we don't have a clear reproduction process for this, we're going to address it for now by adding an explicit check prior to the line where the panic originated so that we can at least fail gracefully in this weird edge-case. If it crops up again then we'll dig further and try to get to the bottom of it.

Thanks again for reporting it!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.