-
-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stackoverflow exception #139
Comments
Hmm, thanks for finding. Could you check what happens if you set the rule:
|
Hey! Thanks I did some testing with and without fastExpressionCompiler and it seems the issue is there. This is the configuration we used by default. Dim container = New Container(
Function(rules)
Return rules.With(FactoryMethod.ConstructorWithResolvableArguments)
End Function
).WithWebApi(config) Then to disable fast expression compiler we used this code: Dim container = New Container(
Function(rules)
Return rules.WithoutFastExpressionCompiler().With(FactoryMethod.ConstructorWithResolvableArguments)
End Function
).WithWebApi(config) Here are the results:
We also noticed CPU usage is way better without fast expression compiler, maybe its related to the bug or something else. Anyway this workaround works for us. Thanks for your help |
..Interesting, thanks for the info. Will check from here. |
Hi @Havunen Could you help to verify something? Replace |
I did quick test and it seems |
Thanks for checking. |
Today this issue started happening in our development server, even without fast expression compiler. new Container((rules) =>
rules.WithoutFastExpressionCompiler().With(FactoryMethod.ConstructorWithResolvableArguments)
); Here is crash dump:
.Net callstack
|
I managed to hit debugger on this stack overflow exception. I will try to add details on this thread to help getting it fixed |
Inside Parameters: Callstack starts from On a side note, I had breakpoint on this line in container.cs |
It seems like
but I'm not sure if thats due to invalid state of debugger or if it actually happened |
It seems like stackoverflow exception happens inside |
Strange, maybe just maybe we have a recursive dependency here.. |
I debugged this further and realized its cycling between TryInterpret and TryInterpretMany always returning true and its going into |
Ok, this is pretty close! |
Yeah commenting out decorator registration fixes the issue. I need to investigate further why it breaks it. |
Could you try another option to decrease the number of culprits: Assuming that your object graph is deeper than 20 levels. |
Thanks for the idea, but it didn't work :/ Its still crashing |
Actually it is good to know.. So we need to look into |
It feels like there is some sort of pattern when this happens. Looks like GC hits and then quickly after that it crashes the application pool. Not sure... |
Or maybe GC is just trying to clean the stackoverflow situation |
I tried moving disposable handling inside the lock but that didn't matter |
It looks like making all decorators singleton fixed the issue. We had not defined Reuse in decorators previously |
There are some other options for Decorator registration to try:
|
I tried with singleton decorators and it still fails if I dont add |
Ok, good to know as well. |
I'm working on test case to reproduce this issue, I'm also trying to reproduce #137 same time. This is slow progress it will be huge app... |
Thank you. |
I'm traveling for a week. I will get back to this when I'm back home. |
Opened PR #162 to reduce this issue, but it will not fix this it only makes it less likely to happen. One might have even larger expression tree than what is in LoadTest. |
I have fixed |
Nope, seems like a different thing, cause it is inside the Interpret call and not inside the compiled delegate. Did you try v4.1 preview packages? |
I use v4.0.7 var container = new Container(rules => rules
.WithoutThrowOnRegisteringDisposableTransient()
.WithTrackingDisposableTransients()
.WithAutoConcreteTypeResolution())
.WithMvc(
controllerAssemblies: new[] { Assembly.GetExecutingAssembly() },
throwIfUnresolved: type => Debugger.IsAttached && type.Name.EndsWith("Controller"));
container.Register<ILogger, LogWrapper>();
container.Register<IAppConfig, AppConfig>(Reuse.Singleton);
container.Register<IEmailService, EmailService>();
container.Register<IHelperService, HelperService>();
container.Register<IBankFileConverter, BankFileConverter>();
new AllModules(container); I will try the preview |
Hmm, not funny. Thanks for the code. Will check later. Just for experiment, could you try to add this to setup: .WithDependencyDepthToSplitObjectGraph(5); Btw, you don't need .WithoutThrow for transient disposables if you have .WithTracking... Also, do you really need AutoConcreteTypeResolution? it is kind off fragile auto-magic thingy and may hide the registration problems. Just asking. |
@alexandre-machado Have you tried |
updated copyright dates for DryIoc.Web package
fixed dadhi#139 LoadTest downgared to 2.5 min for 4th test
Has there been any progress with this issue? Its taking quite long time to get resolved. @dadhi Are you planning to split the stack or do you have some other strategy in mind? |
@Havunen Are you still having SO? |
@dadhi I think SO still happens if FEC is used. We are currently using |
@Havunen Just to be fully clear, and you are using 4.1 preview? |
Yeah, we are using DryIoc 4.1.0-preview2 |
Will try to use the approach from #176 and decrease the default split level |
Hi @Havunen Here are the latest results with the released https://www.nuget.org/packages/DryIoc.dll/4.1.0-preview-04 * Fix results:
* - singletonDecorators: true - 00:00:33.65
* - singletonDecorators: false - 00:01:04.08
* - WithUseDecorateeReuseForDecorators and singletonDecorators: false - 00:00:42.31
so I am considering the initial issue closed. Btw, check the new benchmarks in readme... this release is pushing really hard and maturity is higher as well Thanks for all the work! Cheers |
Hi,
I have been investigating an issue where w3wp.exe process crashes under heavy load. I was finally able to get memory dump of crashing process and it seems to come from DryIoc.
Here are details of Thread 51.
.Net Call Stack
Full Call Stack
This is blocker for us to start using DryIoc. This is really strange error, it does not seem to happen in Debug mode and performance seems better in Debug. When built in Release this error occurs and CPU spikes way more. Maybe it has something to do with Jit compiler
The text was updated successfully, but these errors were encountered: