InsufficientExecutionStackException during model binding

[martincostello]

Describe the bug

During a GET request to an MVC action, an exception of type InsufficientExecutionStackException was thrown.

Insufficient stack to continue executing the program safely. This can happen from having too many functions on the call stack or function on the stack using too much stack space.

System.InsufficientExecutionStackException: Insufficient stack to continue executing the program safely. This can happen from having too many functions on the call stack or function on the stack using too much stack space.
   at void System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack()
   at bool Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
   at bool Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel)
   at void Microsoft.AspNetCore.Mvc.ModelBinding.ObjectModelValidator.Validate(ActionContext actionContext, ValidationStateDictionary validationState, string prefix, object model, ModelMetadata metadata)
   at void Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.EnforceBindRequiredAndValidate(ObjectModelValidator baseObjectValidator, ActionContext actionContext, ParameterDescriptor parameter, ModelMetadata metadata, ModelBindingContext modelBindingContext, ModelBindingResult modelBindingResult)
   at async Task<ModelBindingResult> Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, object value)
   at void Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider+<>c__DisplayClass0_0+<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
   at async Task Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
   at async Task Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextExceptionFilterAsync()

The action is defined as thus:

[HttpGet]
[Route("{id}", Name = "MyRoute")]
[Produces("application/json", Type = typeof(MyViewModel))]
[ProducesResponseType(typeof(MyViewModel), StatusCodes.Status200OK)]
[ServiceFilter(typeof(IdValidationFilterAttribute))]
public async Task<ActionResult<MyViewModel>> Index(string id, CancellationToken cancellationToken = default)
{
    //
}

This issue looks similar to aspnet/Mvc#7357.

To Reproduce

Unknown, occurred during a normal GET request to a JSON resource in an ASP.NET MVC 2.2.0 application.

Expected behavior

Request succeeds.

Additional context

Application uses ASP.NET Core 2.2.0 and in-process IIS hosting.

[pranavkm]

@martincostello what's CompatibilityVersion in your application set to? In addition, are these the only two parameters being bound? For instance, it's not clear what IdValidationFilterAttribute does. A repro app would be super useful

[martincostello]

We have CompatibilityVersion.Version_2_2 set.

The code for the filter is as below:

namespace MyApp
{
    public sealed class IdValidationFilterAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext context)
        {
            if (context.ActionArguments.TryGetValue("id", out object value) &&
                value is string id &&
                long.TryParse(id, NumberStyles.Integer, CultureInfo.InvariantCulture, out long _))
            {
                context.Result = new NotFoundResult();
                context.HttpContext.Response.StatusCode = 404;
                return;
            }

            base.OnActionExecuting(context);
        }
    }
}

[martincostello]

We've only had one instance of this exception in the last 30 days, which was today, so I'm not sure what we could do to repro it with a simple app at the moment.

[pranavkm]

That's super weird. The error from aspnet/Mvc#7357 is fairly consistent for a given model type and neither of the two parameter types from your action fit the bill. I'll go over the code once over to see we don't have any latent caching bugs in our code that might produce this exception.

[martincostello]

I've just realised from further review that this error isn't coming from the action associated with the URL, but from the error handler for that URL. I noticed that from the ActionName in the logs:

MyApp.Controllers.ErrorController.Error (MyApp)

The action for the error handler is as thus:

[IgnoreAntiforgeryToken]
[Route("/error", Name = "Error")]
public IActionResult Error([FromQuery] int? id = null)
{
}

and error handling is configured like this:

app.UseExceptionHandler("/error")
   .UseStatusCodePagesWithReExecute("/error", "?id={0}");

Could it be that if the original action throws an exception, the model binding for the re-execute for the error page is getting stuck in a loop of some sort?

[martincostello]

This morning after last week's single isolated instance of this error, this morning in the last 3 hours we've had 58 instances.

They all occur during the execution of an error handler after a different exception is throw in the intended action method.

[pranavkm]

Could it be that if the original action throws an exception, the model binding for the re-execute for the error page is getting stuck in a loop of some sort?

@Tratcher, any ideas?

[Tratcher]

With 2.2 did you move to the new in-proc IIS server? The smaller default stack size there has been a problem. @pakrym

[martincostello]

We did a two step migration. First we went to 2.2, then later we enabled in-process hosting.

At first we ignored in-process hosting due to #4398, then because of #4789 we decided to try in-process with the workaround for 204s so we could still upgrade. We then had to abandon that due to these stack issues, so now we’re back on 2.1.6.

[pranavkm]

I had a look at this, and I don't see an MVC specific issue here. It's fairly likely that the combination of the smaller default stack size with in-proc IIS, the additional stack frames you'd get with an exception thrown that'd result in the error handler being used and calling in to an error handler could have exhaust the stack. Addressing the stack size issue is being tracked via https://github.com/dotnet/coreclr/issues/21450. Closing since there isn't any additional work to be done within MVC.