The Bicep server crashed 5 times in the last 3 minutes. The server will not be restarted. #16219
Assignees
Labels
Comments
|
I downgraded bicep extension version to 0.32.4 and also turned off auto update for this extension - that seemed to have helped. |
|
Re-opening as this looks like a genuine bug in the latest version of Bicep. @average-everyman if possible, would you mind sharing the .bicep file which you are opening that causes the extension to crash? |
|
Here's the stack trace from the error log - I've replaced the repetition causing the stack overflow and added |
|
I cannot share the Bicep output or Bicep file being compiled for confidential reasons, however we are seeing the exact same repetition of these two lines in the bicep output as @average-everyman has attached: |
|
@anthony-c-martin apologies, I am also not able to share the bicep project I am afraid... |
|
Hi all! My VS Code has also been throwing these stack traces when I've been working on an application gateway module. This has also impacted our DevOps pipelines (which was harder to troubleshoot as the stack trace isn't visible in the pipeline outputs). I started testing locally originally with PowerShell using Long story short, I started to try to isolate the problem as I could build other templates (including the AVM public IP address resource) and I found the "offending" code in our public IP address module our app gateway template was using. The code was an @description('The public IP address of the public IP address resource.')
output ipAddress string = contains(publicIpAddress.properties, 'ipAddress') ? publicIpAddress.properties.ipAddress : ''Swapping this output value with what was in AVM has let me progress. Repro Steps
AzCLI Detailsaz version{
"azure-cli": "2.67.0",
"azure-cli-core": "2.67.0",
"azure-cli-telemetry": "1.1.0",
"extensions": {
"bastion": "0.3.0"
}
}az bicep version
A colleague could
|
|
@MattDaines thanks for sharing. I was able to repro as well with the AVM module, and was able to turn this into a minimal repro which causes the same issue on my machine: @description('Required. The name of the Public IP Address.')
param name string
resource publicIpAddress 'Microsoft.Network/publicIPAddresses@2023-09-01' = {
name: name
location: resourceGroup().location
sku: {
name: 'Basic'
tier: 'Regional'
}
properties: {
publicIPAddressVersion: 'IPv4'
publicIPAllocationMethod: 'Static'
idleTimeoutInMinutes: 4
ipTags: []
}
}
@description('The public IP address of the public IP address resource.')
output ipAddress string = contains(publicIpAddress.properties, 'ipAddress') ? publicIpAddress.properties.ipAddress : '' |
|
I used git bisect to narrow it down to this PR: #15825. @jeskew, could you take a look? This hasn't changed in a long time, but removing the element from the "visited" list here feels suspect as it undercuts the original intention of avoiding infinite recursion: As far as I can tell, this is what's causing us to get stuck recursing, but it's not clear why the above PR would have impacted this, and why this hasn't been a problem before. Here's the test case I used with bisect: [TestMethod]
public void Test_Issue16219()
{
// https://github.com/Azure/bicep/issues/16219
var result = CompilationHelper.Compile("""
@description('Required. The name of the Public IP Address.')
param name string
resource publicIpAddress 'Microsoft.Network/publicIPAddresses@2023-09-01' = {
name: name
location: resourceGroup().location
sku: {
name: 'Basic'
tier: 'Regional'
}
properties: {
publicIPAddressVersion: 'IPv4'
publicIPAllocationMethod: 'Static'
idleTimeoutInMinutes: 4
ipTags: []
}
}
@description('The public IP address of the public IP address resource.')
output ipAddress string = contains(publicIpAddress.properties, 'ipAddress') ? publicIpAddress.properties.ipAddress : ''
""");
} |
jeskew
added a commit
that referenced
this issue
Jan 28, 2025
…perty flags (#16235) Resolves #16219 The server crash reported in #16219 was caused by https://github.com/Azure/bicep/pull/15825/files#diff-7d66583c4922f57735a4eac96cd074d356e8eace34ec5900860f093f3d0cbc69R701. The FindPossibleSecretsVisitor relies on object identity to detect and stop infinitely walking recursive types, and the linked line caused otherwise identical object types within the assigned type of a `resource` symbol to have different identities. ###### Microsoft Reviewers: [Open in CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/Azure/bicep/pull/16235)
Hi, this has been closed, but Bicep is still crashing - Bicep CLI version 0.33.13 (48521b9) |
|
yes also crashing for me in Azure DevOps Microsoft hosted agent running with |
|
The fix is included in 0.33.93. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bicep extension in VS Code started crashes after startup since few days ago.
I can see this issue was reported here, but the solution provided does not solve the problem. Furthermore, if as per advice, the setting
dotnetAcquisitionExtension.existingDotnetPathis removed, it gets re-added on vscode startup with the value of an empty list.Please find the attached output from bicep extension.
bicep_server_crash.log
The text was updated successfully, but these errors were encountered: