Friday, October 16, 2015

One of our apps was leaking memory. This passed unnoticed for few years but as the app is used by more and more users, the leak became problematic. The app pool memory had been growing to few gigabytes until the pool was recycled every 24 hours.

The first thing to do in such case is to determine if the leak is caused by a managed code or rather an unmanaged code. This can be done with performance counters. Then, the DebugDiag can be used to collect a memory dump and then the dump can be analyzed to find what objects occupy the memory.

In our case it turned out the Unity container was the culprit or rather, an unfortunate implementation of a unity controller factory for ASP.NET MVC:

public System.Web.SessionState.SessionStateBehavior GetControllerSessionBehavior(

RequestContext requestContext,

string controllerName )

{

return System.Web.SessionState.SessionStateBehavior.Default;

}

#endregion

}

There is an idea behind such factory – it tries to be smart.

If a controller type is registered, it uses the container to resolve an instance. This is to allow constructor injection.

If a controller type is not registered, it still allows property injection assuming the type is decorated with an attribute.

Since this is a multitenant app, the factory uses a child container to be able to configure services differently for different tenants (obviously, looking at the code, the idea of conditional registrations depending on the tenant was never implemented).

Unfortunately also, this is not obvious why this code lacks the memory.

The problem is the way Unity creates a child container. By inspecting the source code I can learn that the CreateChildContainer method actually calls new UnityContainer( this ) which is implemented as

private UnityContainer(UnityContainer parent)

{

this.parent = parent;

if (parent != null)

{

parent.lifetimeContainer.Add(this); // <- culprit!!!

}

...

}

The obvious thing here is that the child registers itself in the lifetime container of the parent which means that consecutive children will make the list grow and grow. And of course there is a way to “unregister”:

An important issue that potentially occurs here is what happens in a concurrent environment where controllers are created upon user requests so that child containers are constantly added and removed from the parent container list. And of course, List<T> methods for adding/removing items are not thread safe.

It turns out fortunately, that Unity doesn’t use just a List<T> for the lifetimeContainer list, rather it has a custom implementation of a synchronized list that locks adding and removing making it thread safe.

About

I am a software architect and an academic lecturer. I've been awarded Microsoft MVP in C# Architecture between 2005 and 2010. Got a PhD in computer science in 2008.
Currently I work mostly with C# and Javascript and love both languages. I consider myself a design/architecture patterns evangelist.
In 2003 I wrote first Polish book on C#/Windows programming, "Windows oczami programisty" (Windows through the eyes of a programmer) (the book is out of print)