-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Race condition in ControllerActionInvoker causes NullRef #5807
Comments
That's this code https://github.com/aspnet/Mvc/blob/rel/1.1.2/src/Microsoft.AspNetCore.Mvc.Core/Internal/ControllerActionInvoker.cs#L1233 What comes to mind is if there is some kind of crazy unanticipated method signature. Sporadic says that either there's one rarely used method that's causing issues or it's a race condition |
Actually, I spaced on this part |
I can't reproduce it, I only got this error occasionally when running parallel integration tests on some compression middleware. It might be some kind of race condition? The error is rethrown at await _next(context) where _next is the RequestDelegate.
|
Getting same exception:
Occurs randomly when executing random action. One of such actions looks like this:
Maybe at ControllerActionInvoker.InvokeActionMethodAsync controller is null or became null somehow before calling
or
BTW using autofac as IServiceProvider but is seems no matter because controller is being created by DefaultControllerActivator |
I suspect that the issue here is a race condition in https://github.com/aspnet/Mvc/blob/rel/1.1.2/src/Microsoft.AspNetCore.Mvc.Core/Internal/ObjectMethodExecutor.cs#L219 It's possible to observe partially-initialized data when a thread has initialized |
Keeping this bug to track the 2.0.0 issue, will add separate issues to port the fix to 1.0.X and 1.1.X |
This change addressed a race condition in the ObjectMethodExecutor where the default argument values array can become visible before it is initialized. If a second observer accesses the array while it is being initialized, it can observe a null value for a reference type parameter, leading to a nullref. The fix here is to make everything immutable and initialize it all up front. There's no reason to create an OME without eventually running it, so there's no downside to doing the initialization up front.
This change addressed a race condition in the ObjectMethodExecutor where the default argument values array can become visible before it is initialized. If a second observer accesses the array while it is being initialized, it can observe a null value for a reference type parameter, leading to a nullref. The fix here is to make everything immutable and initialize it all up front. There's no reason to create an OME without eventually running it, so there's no downside to doing the initialization up front.
Can we expect a release in the 1.1.x cycle with this fix very soon? |
@elangelo we are working to get this into our next patch release; no ETA on that right now unfortunately. But we're hoping for next month (there are several bug fixes we want to get in). |
This change addressed a race condition in the ObjectMethodExecutor where the default argument values array can become visible before it is initialized. If a second observer accesses the array while it is being initialized, it can observe a null value for a reference type parameter, leading to a nullref. The fix here is to make everything immutable and initialize it all up front. There's no reason to create an OME without eventually running it, so there's no downside to doing the initialization up front. (cherry picked from commit 8f4ca32)
This change addressed a race condition in the ObjectMethodExecutor where the default argument values array can become visible before it is initialized. If a second observer accesses the array while it is being initialized, it can observe a null value for a reference type parameter, leading to a nullref. The fix here is to make everything immutable and initialize it all up front. There's no reason to create an OME without eventually running it, so there's no downside to doing the initialization up front. (cherry picked from commit 8f4ca32)
An unhandled exception occurs very rarely in this WebApp hosted in Kestrel.
I have attached a section of the stacktrace - anything in between is just rethrowing of the exception.
Please let me know if this is an issue inside Mvc or if I should be handling it elsewhere.
...more stuff...
The text was updated successfully, but these errors were encountered: