Tracking Memory Leaks In Xamarin With The Profiler – Part 2

Following on from the original Tracking Memory Leaks In Xamarin With The Profiler – Part 1, there are additional techniques to help pin point a leak in memory. Finding the cause of a memory leak is tedious work, but it can be done with the Xamarin Profiler. In this post, I will go through step by step on how to track down, even the smallest of leaks. It is assumed you have read Tracking Memory Leaks In Xamarin With The Profiler – Part 1, and you have a basic understanding of using the memory profiler.

Scenario Setup

First, we need to define a number of actions, you perform within your app, that you wish to check for a memory leak. In this example, the app starts up, then we move to the second page, then we move back. In this scenario, everything in the second page should be disposed of. But what we will be doing here, is adding objects to a global static list.

for (int i = 0; i < 100; i++) 
    App.List.Add(new Data() { Text = "Hello" });

Start the Profiler, by going Analyze > Xamarin Profiler. Next we want to choose Allocations.

Establish Baseline

Now that it is profiling, press the snapshot button multiple times, until the amount of new objects created is equal to zero. We press snapshot multiple times, because we want to make sure all objects have either been disposed of, or are finished being created.

Next, perform the series of events you wish to test. In this case, go to the second page, then pressing back to the first page. Then, press the snapshot button multiple times, until the amount of new objects create is equal to zero. This is our actual baseline, without all the objects that were created on startup.

Finally, perform the sequence of events again, and then press the snapshot button multiple times, until the amount of new objects created is zero.

What we have done here, is performed the same action in your app, that should have made all live objects in first attempt, be disposed of.

Find Live Objects

With this completed, we now go to our snapshot #6. In here, all the new objects that were created, the first time you completed the sequence of events, should all be disposed of. If there are any live object remaining, we have ourselves a memory leak.

In the sample, I purposely added a memory leak, where 100 objects are added to a static list. If we double click the snapshot, we can see the a number of objects. We don’t know which one, if any, contain live objects, we have to check each one individually. (Side note: Xamarin could easily make this experience better, hopefully they will improve the tool over time). But for the sake of this demo, we can quickly jump to the section where we know the leak is.

Lets check the MemoryLeak.Data objects, and in here we will see that are all still live, as indicated by the green dot. This means, they were created in the first attempt, and they are still live.

If you check over other objects, you will notice they do not have a green dot, this is because they are no longer live, and were disposed of.

Finding The Cause

To pin point the memory leak, you can Show in Call Tree, to see where this item was created. From here you can look in the code and see what in the method is creating the objects. You can then decide to change the code, or create a dispose method to clean up, after the page has been popped. Note: Doesn’t show what is holding the reference though. For this you will want to look at the Path to Roots, however this isn’t always filled out.


XAMARIN.FORMS MONTHLY NEWSLETTER

JOIN 1,000+ SUBSCRIBERS

  1. Don't miss out on updates
  2. The latest info from this site, Xamarin and the community
  3. Unsubscribe at any time*

* We use MailChimp, with double opt-in, and instant unsubscribe

Microsoft MVP | Xamarin MVP | Xamarin Certified Developer | Exrin MVVM Framework | Xamarin Forms Developer | Melbourne, Australia

Related Posts

Leave A Comment?