Scoped call to Resolve() with args seems to leak memory

[Leszek-Kowalski]

Hi,
It seems that call to Resolve() with args on a scope leads to memory leak with many LightExpressions in root container`s registry. They are not being removed by Dispose() call.

[affects DryIoC.dll 3.1.0-preview-07 and master as well]

        [Test]
        public void Scope_Args_ShouldNotLeakMemory()
        {
            var container = new Container();

            container.Register<ScopedService>(Reuse.InCurrentScope);
            container.RegisterPlaceholder<ScopedServiceConfig>();

            var startMemory = GC.GetTotalMemory(true);

            for (int i = 0; i < 100000; i++)
            {
                using (var scope = container.OpenScope(42))
                {
                    var scopedService = scope.Resolve<ScopedService>(args: new[] { new ScopedServiceConfig() });
                }
            }

            var endMemory = GC.GetTotalMemory(true);
            Assert.Less(endMemory, startMemory * 2);
        }

        class ScopedService
        {
            private readonly ScopedServiceConfig config;

            public ScopedService(ScopedServiceConfig config) => this.config = config;
        }

        class ScopedServiceConfig
        {
        }

Do you want me to look for less hacky means of testing it and to create a PR?

Are there any workarounds ?

[dadhi]

Thanks for posting.

The problem is that ScopedServiceConfig used as key in resolution cache, but you are recreating it each time and it does not implement GetHashCode and Equals.. so no chance for container to reuse the cache.

Add GetHashCode and Equals and re-check, if no memory leak, then it works fine.

[Leszek-Kowalski]

Thanks for your reply.
What do you mean by 'used as key' ?
The core purpose of args is to have different transient object (with different hash) every time. I would register it otherwise.

My understanding is args are one time use and should not leave any trace it the registry.

[dadhi]

Make sense, will re-check what's going on there. Now, it will be much faster without cache anyway with interpretation in place.