-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Terraform CRASH after updating terraform version to 1.6 #33977
Comments
Confirming that after I rollback the version to 1.5.7 the apply command is working fine. |
I can confirm that this is also happening for |
Thanks for the reports. It may not be necessary pending review by the devs, but if you do figure out a minimal config that causes the crash, that is always helpful. |
I found a way to reproduce: output "test" {
value = var.test != null ? var.test : ""
}
variable "test" {
type = string
default = null
sensitive = true
} Try a |
Thanks @Erouan50! I'm also going to add this stack trace, which is slightly different but will probably be addressed in the same upstream patch:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Attaching Stack Trace here as well
|
For us it crashes on 1.6 on |
Same bug on a destroy. |
Our CI wasn't pinned at a specific TF version and upgraded us automatically. We've rolled back to !!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
Terraform crashed! This is always indicative of a bug within Terraform.
Please report the crash with Terraform[1] so that we can fix this.
When reporting bugs, please include your terraform version, the stack trace
shown below, and any additional information which may help replicate the issue.
[1]: https://github.com/hashicorp/terraform/issues
!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
goroutine 23934 [running]:
runtime/debug.Stack()
/opt/hostedtoolcache/go/1.21.1/x64/src/runtime/debug/stack.go:24 +0x5e
runtime/debug.PrintStack()
/opt/hostedtoolcache/go/1.21.1/x64/src/runtime/debug/stack.go:16 +0x13
github.com/hashicorp/terraform/internal/logging.PanicHandler()
/home/runner/work/terraform/terraform/internal/logging/panic.go:58 +0x13b
panic({0x2b92ec0?, 0x38c4c30?})
/opt/hostedtoolcache/go/1.21.1/x64/src/runtime/panic.go:920 +0x270
github.com/zclconf/go-cty/cty.Value.assertUnmarked(...)
/home/runner/go/pkg/mod/github.com/zclconf/go-cty@v1.14.0/cty/marks.go:141
github.com/zclconf/go-cty/cty.Value.AsString({{{0x3902720?, 0xc0000d2b41?}}, {0x2e1de40?, 0xc007014378?}})
/home/runner/go/pkg/mod/github.com/zclconf/go-cty@v1.14.0/cty/value_ops.go:1385 +0x47
github.com/zclconf/go-cty/cty.Value.Range({{{0x3902720?, 0xc0000d2b41?}}, {0x2e1de40?, 0xc007014378?}})
/home/runner/go/pkg/mod/github.com/zclconf/go-cty@v1.14.0/cty/value_range.go:53 +0x285
github.com/hashicorp/hcl/v2/hclsyntax.(*ConditionalExpr).Value(0xc000892070, 0xc000c430c8)
/home/runner/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.18.0/hclsyntax/expression.go:745 +0xd35
github.com/hashicorp/hcl/v2/hcldec.(*AttrSpec).decode(0xc0067ab860, 0xc0067957b8?, {0xc006101f30?, 0x10?, 0xc001376d00?}, 0xc000c430c8)
/home/runner/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.18.0/hcldec/spec.go:214 +0x1f5
github.com/hashicorp/hcl/v2/hcldec.ObjectSpec.decode(0xc0067ab4d0, 0xc0067ab4d0?, {0x0, 0x0, 0x0}, 0xc001bdb860?)
/home/runner/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.18.0/hcldec/spec.go:88 +0x1f7
github.com/hashicorp/hcl/v2/hcldec.decode({0x3903ae0, 0xc0019bc4a0}, {0x0, 0x0, 0x0}, 0x0?, {0x3902fb8, 0xc0067ab4d0}, 0x0)
/home/runner/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.18.0/hcldec/decode.go:24 +0x10f
github.com/hashicorp/hcl/v2/hcldec.Decode(...)
/home/runner/go/pkg/mod/github.com/hashicorp/hcl/v2@v2.18.0/hcldec/public.go:18
github.com/hashicorp/terraform/internal/lang.(*Scope).EvalBlock(0xc00104e990, {0x3903530, 0xc003e4e000}, 0xc006795c38?)
/home/runner/work/terraform/terraform/internal/lang/eval.go:71 +0x1ea
github.com/hashicorp/terraform/internal/terraform.(*BuiltinEvalContext).EvaluateBlock(0x0?, {0x3902d18, 0xc001650d10}, 0xc00219b6e0?, {0x0?, 0x0?}, {{{{0x0, 0x0}}, {0x0, 0x0}}, ...})
/home/runner/work/terraform/terraform/internal/terraform/eval_context_builtin.go:282 +0x145
github.com/hashicorp/terraform/internal/terraform.(*NodeAbstractResourceInstance).plan(0xc0066ffa00, {0x391fb60, 0xc00451ca80}, 0x0, 0x0, 0x0, {0x0, 0x0, 0x0?})
/home/runner/work/terraform/terraform/internal/terraform/node_resource_abstract_instance.go:717 +0xb8b
github.com/hashicorp/terraform/internal/terraform.(*NodePlannableResourceInstance).managedResourceExecute(0xc0018f9290, {0x391fb60, 0xc00451ca80})
/home/runner/work/terraform/terraform/internal/terraform/node_resource_plan_instance.go:282 +0x1795
github.com/hashicorp/terraform/internal/terraform.(*NodePlannableResourceInstance).Execute(0x7f0972990970?, {0x391fb60?, 0xc00451ca80?}, 0x78?)
/home/runner/work/terraform/terraform/internal/terraform/node_resource_plan_instance.go:74 +0x8a
github.com/hashicorp/terraform/internal/terraform.(*ContextGraphWalker).Execute(0xc005412000, {0x391fb60, 0xc00451ca80}, {0x7f0972805ca0, 0xc0018f9290})
/home/runner/work/terraform/terraform/internal/terraform/graph_walk_context.go:143 +0xbe
github.com/hashicorp/terraform/internal/terraform.(*Graph).walk.func1({0x3135c40, 0xc0018f9290})
/home/runner/work/terraform/terraform/internal/terraform/graph.go:78 +0x375
github.com/hashicorp/terraform/internal/dag.(*Walker).walkVertex(0xc000e2ad20, {0x3135c40, 0xc0018f9290}, 0xc005b58f80)
/home/runner/work/terraform/terraform/internal/dag/walk.go:384 +0x2e5
created by github.com/hashicorp/terraform/internal/dag.(*Walker).Update in goroutine 17000
/home/runner/work/terraform/terraform/internal/dag/walk.go:307 +0xde8 |
Not sure if that's exactly the same bug: putting a It can be reproduced like so: locals {
password = sensitive("abc")
}
resource "random_password" "test" {
length = 3
}
import {
to = random_password.test
id = local.password # crashes as well with `id = sensitive("abc")`
} And then
But we can make it work by making the sensitive field non-sensitive: locals {
password = sensitive("abc")
}
resource "random_password" "test" {
length = 3
}
import {
to = random_password.test
id = nonsensitive(local.password) # will work too: `id = nonsensitive(sensitive("abc"))`
} Results to:
|
Same also happening on:
|
Thanks for all of the example stack traces, everyone. We've narrowed down a few different problems here and are planning to fix them all in the forthcoming v1.6.1 release. There's no need to share any further examples here, since we have what we need to reproduce the problem. These are all slightly incorrect details in the handling of the new v1.6.0 behaviors to perform more precise analysis of unknown values, such as tracking when an unknown value is known not to be null so that We labelled this as "upstream" earlier because the bugs are actually in two libraries that Terraform depends on, rather than in Terraform itself: my personal Therefore the fixes for these will actually appear in those upstream libraries, but we'll use this issue to represent upgrading Terraform's dependencies on both libraries to use the fixed versions, once they are available. |
Thanks again everyone for sharing your stack traces above! We've now merged some fixes that will be coming in the forthcoming v1.6.1 release. As I mentioned above, these bugs resulted from some interactions between the new cross-cutting unknown value refinements feature and some other Terraform language features, and with cross-cutting changes like this one it's possible that similar things will crop up in other locations too. If you've seen a problem that seems similar to the ones described here even after upgrading to Terraform v1.6.1 (once it's available), please open a new issue to discuss it just because adding new bugs onto this closed issue is likely to cause us to miss things. |
Terraform Version
Terraform Configuration Files
I don't think the configuration has any impact here, since this crash has started after the release of the new version.
We aways install the lastest version of terraforms in our pipeline machines.
Providers:
Debug Output
Expected Behavior
The terraform apply should have run successfully.
We had releases that ran fine 6 hours ago.
Actual Behavior
Terraform Apply is crashing even before the execution plan is made.
Steps to Reproduce
terraform init
terraform apply
with terraform 1.6.0
Additional Context
No response
References
No response
The text was updated successfully, but these errors were encountered: