Silverlight application memory leaks detector

• Download source code - 1.18 KB

Currently there is no memory profiler for Silverlight

If you’ve ever programmed in Silverlight, you’ve probably wondered whether your objects in memory were collected by the GC (garbage collector) or not. What if the objects you create stay in the memory for the whole life-time of your application – will you know?

Regular .NET memory profilers don’t work with Silverlight applications, and therefore, if we have a memory problem and want to examine it, the only way to approach the problem is to convert our project to a WPF application, which is difficult in the best of cases, and in my scenario, was nearly impossible.

When should you use a memory leak detector?

The memory leak detector I wrote is meant for use in those cases where you have the feeling one of the objects you wrote isn’t being collected when it should be by the GC. You can use the memory leak detector to monitor this behavior.

How to use the Silverlight application memory leak detector?

To use my memory leak detector, first add the object you want to monitor by calling the detector’s AddReference method in the object’s constructor. Next, at a point where the object should have been already collected by the GC, call the Check method to verify that it was indeed collected and is no longer in memory.

How is the GC duped into collecting objects despite the fact that the memory leak detector has references to them?

The trick behind this memory leak detector is the usage of the WeakReference class. WeakReference is a class that provides the ability to reference an existing object in memory, without preventing the object from being collected by the GC. For more information about the WeakReference class, visit here.

The code – an overview

The memory leak detector manages a main list named elementsList consisting of ObjectStruct elements. Each element contains a WeakReference to the monitored object and a few other debug values. You can use the StackTrace() in order to identify the monitored object’s creator. This field can help find the source of the memory leak.

The code is divided into three main static, public methods. The first two must be called, while the last one, SignalDisposed, is for further debugging.

Main methods:

• AddReference - Adds the object you want to monitor to the memory detector. You can choose whether you want to create the ‘StackTrace’ upon creating the object or not. The object’s constructor is a good place to call this method.

[Conditional("DEBUG")]
public static void AddReference(object obj)
{
    lock (lockObject)
    {
        // avoiding dups - can happen when adding
        // an element and its base-class to the profiler
        if (elementsList.Any(p => p.Reference.IsAlive 
                     && p.Reference.Target == obj))
            return;
        elementsList.Add(new ObjectStruct(new WeakReference(obj), 
                         generationCounter, new StackTrace().ToString()));
        //elementsList.Add(new ObjectStruct(new WeakReference(obj), 
        //                 generationCounter, null));
    }
}

• Check – Use this method to check the memory condition. A good place for implementing this call would be an idle state of your application, where most of the objects already created can be disposed and collected. Each call to the Check method increases the static generation counter by 1, providing us a method for following when the monitored objects where instantiated. The Debugger.Break() command stops the application at a point, allowing you to examine all objects alive in memory.

[Conditional("DEBUG")]
public static void Check()
{
    lock (lockObject)
    {
        long memUsage = GC.GetTotalMemory(true);
        for (int i = 0; i < elementsList.Count; i++)
            if (!elementsList[i].Reference.IsAlive)
                elementsList.RemoveAt(i--);
    }
    generationCounter++;
    Debugger.Break();
}

• SignalDisposed – My experience hunting for memory leaks with this detector during my work on our semantic web Firefox add-on, led me to the conclusion that there is value in having a boolean variable indicating whether or not the Dispose method of the monitored objects was called. To debug your leak, call this method within the Dispose() method to detect scenarios where the Dispose() method was called but the object remains in memory.

[Conditional("DEBUG")]
public static void SignalDisposed(object obj)
{
    lock (lockObject)
    {
        var objectsToSignal = elementsList.Where(p => p.Reference.IsAlive 
                              && p.Reference.Target.Equals(obj));
        if (objectsToSignal.Any() && objectsToSignal.Count() == 1)
        {
            var objectToSignal = objectsToSignal.First();
            objectToSignal.DisposedSignaled = true;
        }
    }
}

Notes:

1. All three functions have the Conditional(“DEBUG”) attribute that allows using the memory leak detector freely in a project without worrying about performance in the release version of the application. For more information about the Conditional attribute, visit here.
2. The class is thread-safe.

Ideas for future development

Knowing which object holds a reference to the in-memory monitored objects would be great…