Terraform 0.7.6 crash during refresh with azurerm provider

[cchildress]

Terraform Version

0.7.6 (was last working in 0.7.3)

Affected Resource(s)

• azurerm_virtual_machine

Terraform Configuration Files

Link

Debug Output

Link

Panic Output

Included with the config files.

Expected Behavior

Terraform should have been able to refresh and build a new plan.

Actual Behavior

Terraform hits a SIGSEGV during the refresh and writes out a crash log.

Steps to Reproduce

1. Run terraform refresh using the above config

Important Factoids

Another group here is using Terraform 0.7.4 against the same Azure account, but in different resource groups and they have not encountered any issues that lead to Terraform panicking like this.

References

I suspect this is the same failure that I was seeing in issue 8995. I also noticed that issue 9410 appears to have a very similar stack trace, but inside azurerm_virtual_network instead of azurerm_virtual_machine.

[cchildress]

I think I may have found some of the logic that leads to this crash. (Not really enough to open a PR, but I wanted to get this written down before I forget about it.)
Turns out we had one virtual machine where someone had manually enabled boot diagnostics. This was later manually disabled. This probably isn't ideal, but we aren't really using the boot diagnostics and I don't have the boot_diagnostics directive specified in the azurerm_virtual_machine resource so I guess I shouldn't be too shocked to learn it's an uncontrolled parameter.

The actual crash appears to occur starting in this block of code that handles interpreting the boot diagnostics portion of the Azure API response.
Inside flattenAzureRmVirtualMachineDiagnosticsProfile() the results array is populated by dereferencing two pointers from the response data here.
In my crash logs one of the last few things written before the SIGSEGV is the raw API results that came back from Azure. In those results you can see that the diagnostic profile data is missing:

412127 2016/10/20 16:12:43 [DEBUG] plugin: terraform:     "diagnosticsProfile": {
412128 2016/10/20 16:12:43 [DEBUG] plugin: terraform:       "bootDiagnostics": {
412129 2016/10/20 16:12:43 [DEBUG] plugin: terraform:         "enabled": false
412130 2016/10/20 16:12:43 [DEBUG] plugin: terraform:       }
412131 2016/10/20 16:12:43 [DEBUG] plugin: terraform:     },

What I think is happening here is that Terraform appears to blindly assume that if diagnosticsProfile and bootDiagnostics are not nil in the raw results then Azure will have of course returned both the enabled / disabled boolean and the URI for the storage account. It appears that Azure considers it perfectly valid to only return "enabled": false once a virtual_machine has had the boot diagnostics option disabled in the Azure portal. I think *profile.StorageURI inside flattenAzureRmVirtualMachineDiagnosticsProfile() is the specific nil pointer being dereferenced.

Assuming I'm right here I have a new procedure that I think will reproduce this crash:

1. Create a virtual machine in Azure using Terraform (don't specify the boot_diagnostics directive in the config).
2. Go into the Azure portal and enable boot diagnostics on the VM and specify a storage account to store these logs in.
3. Run a terrafrom refresh with debugging logs enabled just to see the raw JSON returned from Azure and confirm that both the enabled and storage_uri keys are present.
4. Go into the Azure portal and disable boot diagnostics on the VM.
5. Run a terrafrom refresh and the refresh should crash as it reads the API results from Azure about this VM.

[cchildress]

@stack72 This can probably be closed. The fix I've been messing with internally is identical to what was merged in PR 10283.

[stack72]

Thanks for letting me know!

[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.