This repository was archived by the owner on Dec 14, 2018. It is now read-only.
StackOverflowException at request middleware #6410
Comments
|
Your code has a stack overflow... Look at the callstack to see what is being repeated... |
|
How could I have a stack overflow under a request handler? only should go throw one time per request. Don't really understand. |
|
So, what's in the call stack? |
|
Here is the call stack, nothing on it
|
|
Can you expand the external code? (click Show External Code) |
|
|
Here it is |
|
@villawad-es What does your controller look like? |
|
|
|
@villawad-es When did the stack overflow start? Did you try removing big pieces of your code until the stack overflow goes away? That might help narrow down which part of the code is causing issues. |
|
Looking at: Are you using the status code middleware to execute an error handler? |
|
@rynowak I'm using the Exception Handler provided by the framework to set custom error pages |
|
@davidfowl I have tried without much success, the error sometimes happens once the request is completed and the response has been received. I have migrated the application to the latest stable version of the core and the only thing that has changed is the way the error is displayed. The stack overflow started when I migrate the application from aspnet 5 to netcore 1.0 |
|
@villawad-es if you can, provide us with a trimmed down version of your application that reproduces the issue and put it on github. |
|
Closing because there is not enough information to reproduce this problem. |
|
we just started receiving this same issue with our middleware in .net core ... hope someone has an idea where this is coming from - definitely not obvious as the callstack is empty. Spent 6 hours diagnosing so far - no dice and easy to reproduce. |
|
@alohaninja If you can provide a repro that would be great. A stack trace and the app code would be great first steps. |
|
Hi @davidfowl - we don't have a lite version of our app for immediate sharing, so this may take some time to put together a simpler SLN to demonstrate. Here is the stack trace once I disabled "Just-my-code" and downloaded .NET Source Symbols...not sure how helpful it is. I stepped through the MyApp.Api.exe!MyApp.Api.Startup.Configure.AnonymousMethod__3_5(Microsoft.AspNetCore.Authentication.JwtBearer.TokenValidatedContext ctx = {Microsoft.AspNetCore.Authentication.JwtBearer.TokenValidatedContext}) Line 279 C# |
|
It seems DI related from looking at both call stacks but hard to say for sure. The error handler and the status code paves middleware both re execute the pipeline so it may be another area of interest |
|
@davidfowl - downloaded the source for Here is the fix for it (commented out the offending code block), but I don't know the intent so someone on the DEV team should articulate what this is supposed to be doing. I suspect this background thread is creating a race condition which ultimately resulted in the SO. This was a difficult one to triage - 1.0.1 .NET Core DI is still using |
|
@alohaninja That code can't be commented out, it's required to make things fast and should be thread safe. The fact that it does fix your issue makes me curious though. Do you have a consistent repro yet? It's likely some race condition, plus how your services are defined. Do you know which service is causing the stackoverflow? /cc @pakrym |
|
Given the complexity of our SLN setup we can't easily share the source, but it is consistently reproducible. Narrowing it down to the above statement should help someone identify it - for now we'll probably just stick with AutoFac until we hear any updates back from you. Here is a stack dump from the background thread created by this method before it dies. |
|
I've opened aspnet/DependencyInjection#555. Closing this bug as it isn't an MVC issue. |
|
@alohaninja it would be super useful if you could identify which service was being resolved and if you could give us the service registrations for that call chain. We could at least begin to identify where to start looking. Regardless, we'll try to identify where the problem is. Thanks for the details. |
|
@davidfowl we have roughly 200+ service registrations so it's not a single service that is causing it to fail. The call chain get's fairly deep depending on what our app is doing. If you or someone who's working on this project are in St. Petersburg - stop in and we'll be happy to demo it to you. I doubt we could easily create a repro SLN given the large # of dependencies. |
|
I can confirm we have this issue as well. I don't know if this is the solution, but I can say that refactoring helped for this instance. This exception is very troubling though as it crashes kestrel |
|
@xxjthxx If you can reproduce the issue it would be amazing if you can send us a code sample. |
|
@xxjthxx Do you happen to have |
|
@pakrym definetely no |
|
@xxjthxx Can you share the service definitions that caused the problem? |
|
@davidfowl For now I only managed to find the exact class (it's a Scoped service) which is causing this by attaching DI source code. Unfortunately I'm not sure all services will help you because this one problem we discovered in our e2e test, not in manual tests or normal usage. This path is highly reproducible though so we could pair programming via skype if you're interested. The exception is in the GetService method and return realizedService.Invoke(this); line. |
@xxjthxx Can you make a project that reproduces the problem? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm experimenting a StackOverflowException at the end of request middleware, I can't understand what's happening.. so simple meddleware and no exception details...
Only exception not null info is:
HResult -2147023895 int
_COMPlusExceptionCode -532462766 int
The text was updated successfully, but these errors were encountered: