Memory Leaks in Managed code

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Q: Can you have memory leaks in
managed code?  If so, how can you
catch them? "urn:schemas-microsoft-com:office:office" />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">A: (From the GC Architect) style="mso-spacerun: yes">  style="mso-spacerun: yes"> GC will typically reclaim objects at its
own pace, based on balancing available memory and runtime overhead. If an
assembly is terminated and it is known to contain a significant percentage of
the total set of managed objects, then calling GC.Collect() after the unload
does make sense.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">If you define a leak as the memory
usage grows over time, then you can have leaks in a GC runtime. If you keep ever
growing datat in a static variable for example. Suppose an editor keeps an
infinite undo list, then this would be seen as a leak. style="mso-spacerun: yes"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As far as leak detection and
diagnosis, you should look at the perfmon counters in the category
. "urn:schemas-microsoft-com:office:smarttags" /> style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">NET style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">CLR style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> Memory You will find a lot of
interesting counters like # object in all heaps. They will tell you if you are
leaking objects.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">You should also check out the
various style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">CLR style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> memory profilers out there. With
them you can get a picture of the heap and by comparing the pictures at 2
different points you can determine which objects are accumulating and then find
out which code path allocates them in the first place, or even, which connected
graph keeps them alive.


Comments (3)

  1. Ashley gr says:

    We’ve a Windows application(rich-client application) which uses set of data in the excel input files and generates around 58 workbooks with each workbook containing around 32 sheets each.

    We tried it in Excel 97.

    Application makes extensive use of the Excel object model to generate the files.

    Application release all the Excel hidden objects using Marshal.ReleaseCOMOBject and it does all this thing correctly to the best of my knowledge. We also call the GC.Collect() & GC.WaitForPendingFinalizer() just to be sure that the memory is cleaned-up. I understand there’ll be a performance hit. But it’s okay as long it’s stable but it’s not the case right now.

    Problem is after 5 successful test runs, without closing the application, Not Enough Memory to Run Microsoft Excel error pops-up and everything is over. After this, i see the same message when trying to launch Excel 97 or Word from my computer. I’ve to restart so as to use any of Office applications again.

    I’d really appreciate someone telling me if there are any bugs in Excel 97 itself that resuls in these or any workaround.

    I need some help ASAP.

    I looked at the log using the PerfMon and the following values:

    Process – Private bytes -> 5.7 MB – 27.1 MB with average around 19 MB

    .NET CLR Memory – #Bytes in all heaps -> 0.312 MB – 3.3 MB with an average value around 0.9 MB

    SInce the above counters are kinda okay, i’m not sure whether there is a memory leak.

    My computer has 256 MB RAM and i’ve set the initial size of the virtual memory to 700 MB.


    Print | Copy URL of this post

    Expand All Collapse All

    Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter

Skip to main content