Stack overflow on v6.3.5+

[sirphilliptubell]

Starting with 6.3.5 I'm getting a strange stack overflow error. We're running a net6.0 web api project that has
LightInject 6.3.5 (and higher versions have the same problem)
LightInject.Microsoft.DependencyInjection 3.3.1
LightInject.Microsoft.Hosting 1.2.1

Stack overflow. at Project.DerivedClass..ctor() at Project.BaseClass..ctor() at DynamicClass.DynamicMethod(System.Object[], LightInject.Scope) at LightInject.ServiceContainer.GetInstance(System.Type, LightInject.Scope) at LightInject.Scope.GetInstance(System.Type) at LightInject.Microsoft.DependencyInjection.LightInjectServiceProvider.GetRequiredService(System.Type) at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(System.IServiceProvider, System.Type) (total stack depth was 105 lines)
In the above stack trace, the DerivedClass only inherits from BaseClass and has nothing else (no fields, properties, methods, or constructors)
BaseClass has no defined constructors nor properties.

The original issue was happening when trying to resolve a controller. I initially wondered if there was some kind of circular dependency issue, but I figured out that if I remove the last constructor argument (even if I switched the order of the constructor arguments meaning it wasn't that specific one) then the issue went away. Also, I went down the dependencies each time removing constructor arguments, and noticed it was always the last one causing the problem. The last & deepest constructor argument had nothing to do with the class listed in the stack trace.

I found that I was able to fix the issue by changing a common dependency lifetime from transient to scope. But this dependency also had nothing to do with the classes mentioned in the stack trace, nor with the item in the last constructor argument.

[seesharper]

Could you create a small repro of this?

[sirphilliptubell]

Its not really feasible as we have a quite large library and I'm not sure what in LightInject could be having trouble.. Is there something I can do to help diagnose the issue?

[seesharper]

I understand. Unless you are able to narrow it down to the simplest thing that fails 😊🤔. If you downgrade to < 6.3.5 it works?

[sirphilliptubell]

yea < 6.3.5 works. I'll see if I can come up with something

[seesharper]

Thanks👍. Appreciate it 👌

[sirphilliptubell]

Continuing from #559..

The issue does happen with the default (LightInject) service provider (not using LightInject.Microsoft.DependencyInjection)

I attempted to export a fake set of classes and interfaces that were registered into a test project, and I had to discard a lot of dto type classes that were registered. In the end I have ~1000 interfaces and ~2800 classes. The actual project at runtime has around ~6800 service registrations as a comparison. (We're using RegisterAssembly() there.) When I run it with the filtered/exported classes and interfaces and try to GetAllInstances() to get all 20, it works successfully so no luck there.

I did notice however that in this test project with ~2800 classes, the memory usage goes from ~100mb to ~950mg when calling GetAllInstances() just to get those 20 the first time. In the actual project we run, it goes from ~115mg to ~5.2gb before throwing the stack overflow.

I feel at this point part of the problem is the sheer number of things registered mixed with whatever changed in 6.3.5.

[seesharper]

Do you see similar memory consumption with 6.3.4 or is that also introduced in 6.3.5?

Any chance you could share your test project? I would at least start with looking at why it consumes so much memory.

[sirphilliptubell]

Just tested it, no memory issues at all on 6.3.4

Here you go

[seesharper]

Great, I'll have a look. What did you use for memory profiling?

[sirphilliptubell]

Thanks! I just used the built-in window in visual studio (VS2022)

[seesharper]

Could you try with version 6.5.0 and then set ContainerOptions.OptimizeForLargeObjectGraphs to true ?

[sirphilliptubell]

That did it, thanks so much! The memory only went up by ~40mb.

Could you pass along the OptimizeForLargeObjectGraphs on the ServiceContainer(ContainerOptions) constructor? The ServiceContainer(Action) constructor is fine.