Finding leaks between memory snapshots

Memory profiling for .NET developers

Finding leaks between memory snapshots

Postby tzunoi » Wed Nov 03, 2010 5:00 pm


Supposing the following scenario:
C# .NET application that has some iterations.
- after I run iteration 1 I do a snapshot - S1.
- I run iteration 2, here some (not all of them - leak) object from iteration 1 should be destroyed (should not be referred anymore) and new ones are created. When it finish I do a memory snapshot - S2.
- I run iteration 3 and some object previously created at iteration 2 are destroyed - not all of them that's the funny part - and new ones are created. This new ones are not destroyed until the end of iteration - and should not be. After iteration 3 ends, I take a memory snapshot - S3.

Idea is that object allocated in previous iteration are destroyed in current ones and I can do snapshots only between iteration - otherwise will be something messy. Also, there are a lot of objects so tracing them by hand is not an option.

Now if I compare S3 with S2 I see all object allocated (ans should be allocated) but also old one that are not destroyed.
I need some kind of object allocated into iteration one (I1) and not destroyed into I2 and object allocated into I2 and not destroyed in I3.

Any idea how could I do this?

By the - way it takes so long to buy a license...I order it 1 week ago and still I don't have serial number.
Posts: 2
Joined: Wed Nov 03, 2010 4:45 pm

Postby AndrewH » Thu Nov 04, 2010 11:24 am


It looks like the 'survivors in growing classes' filter that we've added in v7 of the profiler may do some of what you need. The new categorisation view in the class graph may help as well.

You can get the EA build of version 7 here: ... .php?f=134

From your description, one possibility is that the objects you're having problems with have finalizers (or they are referenced by something with a finallizer, a UI control perhaps). These will cause them to survive at least one garbage collection, and potentially very many if finalizable objects reference each other (in the profiler this will look like they gradually disappear over the course of many snapshots).

The zombie object filter might be worth checking out as well: this will show you any objects that were going to be finalized in the earlier snapshot but haven't been removed in the later snapshot - this can be sign of poor finalizer code that creates new references to the object, forcing it to stay in memory. It can also be a sign of slow finalizer code, which will limit the rate at which .NET can remove the objects.
Andrew Hunter
Software Developer
Red Gate Software Ltd.
Posts: 118
Joined: Thu Aug 17, 2006 2:44 pm

Return to ANTS Memory Profiler Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests