Suggestion: Easy Leak Spotting Technique

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
OmerMor
Posts: 6
Joined: Thu Jan 17, 2008 5:56 pm

Suggestion: Easy Leak Spotting Technique

Post by OmerMor » Thu Jan 17, 2008 7:09 pm

Hi,
First I must say that I love your product! It's a must-have tool.
Since I've used it for so long now, I've "developed" a technique that helps me spot elusive leaks, which I'd like to share:

My first steps are somewhat trivial:
  1. Obtain 2 snapshots from a similiar state in the system. The best way is to run a leaky scenario once; take a snapshot; run it again; take a 2nd snapshot.
  2. Pick a type which has a large instance delta, and go to the type details page for it.
  3. Try to locate instances which should've been removed, and investigate their root paths & allocation call stacks.
The problems often lies in step 3: sometimes the type I'm investigating is very common, and have thousands of "legitimate" instances. In such cases, locating the instances that leaked can become a tedious task.
My "breakthrough" was when I thought about what makes leaky instances differ from the normal ones:
  1. They usually have a unique allocation stack.
  2. They must have new live instances.
  3. They must have live instances which are not new. This is because the 1st snapshot was taken after the same leaky scenario, so instances must have leaked in the 1st snapshot and still be alive in the 2nd, which makes them "not new", or "old".
Using this features of leaky instances, here is how you can spot them in the Type details page:
  1. Go to the allocation stacks tab.
  2. Put the cursor in the Call stack text box.
  3. Observe the details in the bottom: you should look for allocation stacks with at least 1 New live instance, and with more Live instances than New live instances.
  4. If the allocation stack satisfies the rule in step 3, then your leaky instances were allocated with this allocation stack. From here you can press "Select instances" and investigate the highlighted instances, or press "Show root paths for stack" and see why those instances where not collected.
  5. If the allocation stack does not satisfy the rule, press the UP key in the keyboard to cycle to the next allocation stack.
  6. Repeat from step 3.
Here are some examples:

Live instances: 1,234; New live instances: 1,234;
Not a leak. All the instances are new, so instances with this allocation stack from the 1st snapshot did not survive in the 2nd snapshot.

Live instances: 500; New live instances: 0;
Not a leak. All the instances are old, so the leak couldn't have originated from this allocation stack.

Live instances: 8; New live instances: 2;
Probably a leak! There are survivors from the 1st snapshot, as well as new instances from the 2nd snapshot, so this is a great allocation stack candidate for a leak.

I hope I was clear enough, and that my technique will help others in their quest for leak-less applications.

I also hope that SciTech will integrate some sort of functionality that will help automate this method of searching.

Omer Mor.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri Jan 18, 2008 4:12 pm

Thank you for your suggestion.

A future version of .NET Memory Profiler will include a wizard (or something similar) that will guide the user through the process of locating potential memory leaks. When we implement this feature, we will take your ideas into consideration.
Best regards,

Andreas Suurkuusk
SciTech Software AB

mar
Posts: 1
Joined: Sat Aug 30, 2008 8:50 pm

Post by mar » Sat Aug 30, 2008 8:52 pm

OmerMor,
do you offer memory profiling consulting? I'm looking for someone to maybe spend an hour or two profiling my app. email miker@socal.rr.com

Post Reply

Who is online

Users browsing this forum: No registered users and 21 guests