SharePoint Memory Leaks

While working as a developer within SharePoint – farm solutions, every developer has come across Memory Leaks, but what actually are memory leaks and how to defend your code from them?

When a program needs to store some temporary information during execution, it can dynamically request a chunk of memory from the system. However, systems have a fixed amount of available total memory. If one application uses up all of the free memory in a system, other applications will not be able to get the resources they require. The implications of a “memory starved” application can range from a graceful shutdown to an unexpected crash. The majority of large scale applications regularly request memory, so running out of system memory usually leads to a domino effect.

Now, as we already know what memory leaks are, the next question that comes to our mind is, how to find such a leak. If the SharePoint solution is already deployed on a server, the only way to detect a memory leak is to periodically check the amount of memory used by the services and applications. We can either employ Task Manager or any other process explorer within a server to measure the memory usage. Even though finding a memory leak seems a relatively easy task, we also need to investigate which part of the code is responsible for this. Indeed, tools such as WinDbg or Visual Studio may be helpful, but code scanning is quite demanding, especially in the production environment.

The best way to protect your code from memory leaks is to prevent them. However, it is not that easy and requires not only a good code structure but also a high standard development process, constant code reviews performed by experienced developers as well as tools detecting such issues.

Why are memory leaks so frequent in SharePoint and why are they so dangerous? First, let’s have a closer look at a couple of examples of memory leaks and then we will discuss how to prevent them and why they have occurred in the first place.

Example 1

private SPList GetSpList(string webUrl, string listTitle)
{
using (SPWeb web = new SPSite(webUrl).OpenWeb())
return web.Lists.TryGetList(listTitle);
}

Example 1 above shows more than one memory leak:

In the first one, we have created a new SPSite which we do not Dispose – although an SPSite is not as large an object as SPWeb, it may still have impact on the environment it runs in.
In the second one, memory leaks may have occured because the returning type is a SharePoint SPList,which has an object called ParentWeb – which will create a new instance of the SPWeb object that will never be Disposed. This is due to how the SharePoint code is written, so let’s have a look at what is actually happening when we call list, ParentWeb, this is shown in the image below.

The parent web cannot be disposed since the SPList object does not Implement IDisposable so even if we would like to dispose, it is not possible: public class SPList : SPSecurableObject.

Example 2

private SPWeb GetSpWeb(string webUrl)
{
using (SPSite site = new SPSite(webUrl))
{
using (SPWeb web = site.OpenWeb())
return web;
}
}

Example 2 above is a common example of a memory leak. As we Dispose Web and Site objects we are actually returning a Disposed Web object and we start running operations on it. Although the object is Disposed, SharePoint will not show an error stating that we are trying to use an object that doesn’t (or shouldn’t exist), instead the application will create a new instance of the object that will never be Disposed and thus will occupy memory. The reason for such a situation is that SPSite keeps a list of opened webs in the memory, yet these objects have a weak reference which allows the garbage collector to collect an object while still allowing the application to access it, this is shown in the image below.

In image 2, we can see that the SPSite object contains an IEnumerable “objectHandleList”, that contains a member called “TrackedObject”, as shown in the image below and this member is of a “WeakReference” type. While it is required that this object is a “weak reference” type due to its size and possible quantity, unexperienced SharePoint developers might suffer from severe headaches while trying to understand why this happens.

Here are a few pieces of advice how to avoid such mistakes:

Make sure you have your code reviewed by experienced SharePoint developers who focus on possible memory leaks.
Use external tools such as SPCop, which is a part of SharePoint Code Analysis Framework (SPCAF) – unfortunately since May 2005, it is no longer free of charge.

Althought memory leaks are extremely dangerous within SharePoint and can make the whole server get “stuck” or behave “strangely”, there is yet another issue that some developers see more critical, namely disposing the web or site of the current context, as shown in Example 3 below:

private void DoWork()
{
using (SPSite site = SPContext.Current.Site)
{
using (SPWeb web = SPContext.Current.Web)
{
//some code
}
}
}

To conclude, memory leaks are very dangerous within SharePoint and might cause a number of issues, but Disposing the current site or web seems to be even more alarming. SharePoint has already tried to overcome memory leaks by introducing Apps (currently called Add-ins), but the problem still exists in farm and sandbox solutions.