ServiceReference generated DTOs leaking memory

Topics: Prism v4 - Silverlight 4
Dec 21, 2011 at 11:49 PM

I am struggling to understand what is causing DTO's to stay in memory, even though, my VMs are getting GCed (or at least de-referenced).

I used WinDbg and from the returned list, I removed the objects that should still be in memory / or are ready to be collected by GC (this I am verifying by using !GCRoot and checking that no root exits..). However, I got the following list of objects still in memory:

      MT    Count    TotalSize Class Name
035c9d90        1           32 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.StudentDetailDto, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
035c9a1c        1           32 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.Name, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
0351ece4        1           32 System.Func`2[[Resonant.eEnrol.Silverlight.UI.Modules.Academic.Model.ContactShortModel, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
035c8de4        4          128 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.Address, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
5eee17d0        8          160 System.Object[]
035c96a8        5          160 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.Phone, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
035c85b8       10          320 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.EntityType, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]

As can be seen, most of these are the DTOs that I am using in my Model classes (which are used in VMs). IMPORTANT THING is VMs are GCed (or ready to be GCed).

 

Additionally the following is output of my investigation in to few of the above objects:

ContactShortModel (line 3 of the above listing):

0:008> !dumpheap -mt 0351ece4
 Address       MT     Size
0634de20 0351ece4       32     

Statistics:
      MT    Count    TotalSize Class Name
0351ece4        1           32 System.Func`2[[Resonant.eEnrol.Silverlight.UI.Modules.Academic.Model.ContactShortModel, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
Total 1 objects
0:008> !gcroot 0634de20
HandleTable:
    02bd11f4 (pinned handle)
    -> 071d6210 System.Object[]
    -> 0634de20 System.Func`2[[Resonant.eEnrol.Silverlight.UI.Modules.Academic.Model.ContactShortModel, Resonant.eEnrol.Silverlight.UI],[System

Found 1 unique roots (run '!GCRoot -all' to see all roots).

StudentDetailDTO (line 1 of the above listing):

0:008> !dumpheap -mt 035c9d90
 Address       MT     Size
064098e0 035c9d90       32     

Statistics:
      MT    Count    TotalSize Class Name
035c9d90        1           32 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.StudentDetailDto, Resonant.eEnrol.Silverlight.UI],[System.Boolean, mscorlib]]
Total 1 objects
0:008> !gcroot 064098e0
HandleTable:
    02bd11f8 (pinned handle)
    -> 071d4220 System.Object[]
    -> 064098e0 System.Func`2[[Resonant.eEnrol.Silverlight.UI.ResonantServiceReference.StudentDetailDto, Resonant.eEnrol.Silverlight.UI],[Syste

Found 1 unique roots (run '!GCRoot -all' to see all roots).

 

Any more digging in to the System.Object[] addresses doesn't give me anything helpful.

 

Can someone please tell me how to proceed ahead with my memory leak detection? Or, am I worrying unnecessarily......

We have started working on a very large project using SL 5/Prism 4. And I want to make it sure that we (developers) are not doing something which can be painful for us later.

Any help would be extremely helpful.

Thanks,

Dharmesh

Developer
Dec 22, 2011 at 6:58 PM

Hi Dharmesh,

As far as I know, there could be many reasons behind your problem.

Usually, when an object is not being garbage collected, it's because a reference to the object is being kept in some part of your program (e.g. if the object is subscribed to an event, was registered in the container as a singleton instance, etc. )

Based on my understanding, it might also be possible that, if there is no reference to the object and it's ready to be garbage collected, the memory consumed by the object is not being released as no extra memory is required by the system or the application. As explained in the following article: Fundamentals of Garbage Collection - Conditions for a Garbage Collection, a garbage collection operation is performed only when certain conditions are met. If none of the required conditions are met, the objects might not be collected until more memory is required. In this case, you can force the garbage collector to run by invoking the GC.Collect() method; however, take into account that this is not a commonly recommended approach, so you should only use this for debugging purposes.

You might find the following blog post about finding memory leaks, which includes some links to other useful resources, useful:

Also, as this is not be strictly related to Prism, you could find better support about this in the Silverlight forums.

I hope you find this useful,

Damian Cherubini
http://blogs.southworks.net/dcherubini

Dec 22, 2011 at 9:28 PM

Thanks for your explanation Damian.

Yes, I would rather post my problem in SL forum.

 

Thanks again,

Dharmesh