StackOverflowException when deploying a particular release

Your forum seems to have eaten my post from yesterday. Trying again…

We’re running Octopus 3.0.19.2485. It’s been working fine overall, but a deploy of a particular release is consistently failing due to a StackOverflowException, apparently inside Octopus. I’ve attached the log… the relevant part is here:

Deploying package:    C:\Octopus\Files\Pbp.OfflineReporting.WebSchedulerManager.0.0.459.0.nupkg-018b4bc9-40ea-433c-a2e7-ee308ef47468
Using variables from: C:\Octopus\Work\20151125003315-525\Variables.json
Extracting package to: D:\PayByPhone\Releases\Octopus\3.0\staging\Pbp.OfflineReporting.WebSchedulerManager\0.0.459.0
Extracted 136 files
Process is terminated due to StackOverflowException.
The remote script failed with exit code -1073741571

I couldn’t find the file C:\Octopus\Work\20151125003315-525\Variables.json, I assume it’s temporary and Octopus deleted it. I verified that the files were extracted to D:\PayByPhone\Releases\Octopus\3.0\staging\Pbp.OfflineReporting.WebSchedulerManager\0.0.459.0.

This also happens when deploying to a different server, so it’s not specific to the target machine or its tentacle. The failure happens both when deploying to listening tentacles and polling tentacles.

The StackOverflowException happened before our PreDeploy.ps1 contained in the .nupkg logged any output.

After running into this, I tried adding a custom pre-deploy script inline inside the step definition, which just does this:

Write-Host "Test pre-deployment script"

Results (deploying to a different environment):

Extracting package to: D:\PayByPhone\Releases\Octopus3\roadmap-qa\Pbp.OfflineReporting.WebSchedulerManager\0.0.459.0
Extracted 136 files
Executing 'D:\PayByPhone\Releases\Octopus3\roadmap-qa\Pbp.OfflineReporting.WebSchedulerManager\0.0.459.0\Octopus.Action.CustomScripts.PreDeploy.ps1'
 Process is terminated due to StackOverflowException.

So it says it’s executing the custom script, but the custom script doesn’t log any output before the process blows up.

The log file C:\Octopus\Logs\OctopusTentacle.txt doesn’t have anything from the date of the deploy.

Please let me know what we should do next to troubleshoot this issue.

Thanks,
Richard

ServerTasks-7434.log.txt (3 KB)

Hi Richard,

Thanks for reaching out. Is this happening to all your releases and deployments, or is it Isolated to specific releases/projects/environments/etc ?

Could you please send us the Octopus server logs? On a default install they will be on C:\Octopus\Logs

Regards,

Dalmiro

Hi Dalmiro,

Thanks for your help. I ended up figuring it out.

This is due to the loose ends from our Octopus 1 migration a few months ago. Originally Octopus required us to set a variable “OctopusWebSiteName” to configure the IIS path for a site. We have this variable defined in all our older projects.

When we migrated from Octopus 1 through 2 to 3, Octopus set up a Legacy Variable Mappings variable set, mapping OctopusWebSiteName to #{Octopus.Action.Package.UpdateIisWebsiteName}. This never had any effect on our migrated projects, since they all defined OctopusWebSiteName at the project level, overriding what’s in the variable set.

To get Octopus 3 to use the OctopusWebSiteName that we defined at the project level, we configured the “IIS6+ Home Directory” feature, setting “Site/virtual directory” to #{OctopusWebSiteName}. This worked fine as long as we remembered to define OctopusWebSiteName at the project level.

On a new project, the developers configured the IIS Home Directory feature to use #{OctopusWebSiteName}, but didn’t set OctopusWebSiteName in the project variables. So the variable set tried to set it to #{Octopus.Action.Package.UpdateIisWebsiteName}. I assume this caused an infinite loop… since the variable definition is saying to get it from the home directory feature, but the feature is configured to use the variable.

For now I solved the problem by adding the OctopusWebSiteName property at the project level. To avoid this in the future, I’ll remove OctopusWebSiteName from the Legacy Variable Mappings.

Thanks,
Richard

Hi Richard,

Glad to hear you’re up and running.

Cheers!

Dalmiro