Closed mdaniel closed 4 years ago
Thanks for reporting this, @mdaniel.
Based on the location given in that stack trace, it looks like the join
function is trying to return an error with one of its arguments here but it's indicating an incorrect index for that argument and thus the language engine is crashing trying to find the source location of the argument in question to produce a proper error message.
From looking at the source code for join
it seems like indeed there are incorrect argument indices in two of the error messages:
ai
here is an index into the list provided as the second argument, not an index into the argument list. So if any of the list elements aside from the first twp to meet either of those error conditions, this panic is the likely result.
We'll get that fixed up to indicate that argument 1 (the list itself) is the problematic one, but at least knowing what these two error cases are gives a clue as to what the local cause might be: somehow there's a null
in that module.subnets0.networks[*].cidr_block
result.
At first glance it's not clear why there would be null
in that list in this case, since hashicorp/subnets/cidr
should generate a null
only if it's given a network object with its name
set to null
, and that doesn't seem to be the case here. It might help to comment out the local_file.f
resource for the moment and add an output that just returns module.subnets0.networks[*].cidr_block
directly, without using join
, and thus see what the value of that expression actually is. We're not sure yet why it would contain any null
values, but seeing which of the results are null might be a good clue that could lead to a bug either in the hashicorp/subnets/cidr
module itself or in Terraform's expression evaluator.
Thanks again for reporting this!
I tried what I thought was a compromise away from using join()
by trying jsonencode()
, since it is able to theoretically represent a much richer data vocabulary than just join
. But it produced the same explosion when using jsonencode()
as written, with a two element list
# local_file.f will be created
+ resource "local_file" "f" {
+ content = "kaboom = [\"10.128.128.0/21\",\"10.128.136.0/21\"]\n"
_then the same deal when -var the_list=[]
has 3 items_
panic: runtime error: index out of range
goroutine 162 [running]:
github.com/hashicorp/hcl/v2/hclsyntax.(*FunctionCallExpr).Value(0xc0004904b0, 0xc000230c80, 0x0, 0xc00051d700, 0x1, 0x1, 0x0, 0x0, 0x0)
I was playing around further and discovered that my original bug report was more verbose than necessary: just the module
is enough to cause the crash; one need not actually do anything with the module's resources (so, no jsonencode
nor join
required)
I've reproduced this on terraform 0.12.26 and 0.13.0 beta 1, and scripted the reproduction in https://github.com/danieldreier/terraform-issue-reproductions/tree/master/23019 to make it quicker for the engineer who picks this up.
Hi, thanks for reporting this issue! It's working now in terraform built from master, so one of the many commits we've made since beta1 fixed this, too. thanks for reporting it, and for the local reproduction!
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.
Terraform Version
Terraform Configuration Files
Debug Output
As best I can tell,
crash.log
is the output of runningTF_LOG=trace
Crash Output
https://gist.github.com/mdaniel/c68190e74439c8fb391d305ed3aaa9e1
Expected Behavior
Not crashing
Actual Behavior
Steps to Reproduce
main.tf
in the current directoryterraform init
terraform plan -var 'the_list=["a","b","c"]'
you can try it with just
terraform plan
to observe the non-crash-y flavorAdditional Context
I only learned about
hashicorp/subnets/cidr
from the documentation oncidrsubnets
, and hadn't tried it before today