0

I am analyzing a .dmp file for "OutofMemory" exception. The objects are staying in the memory for very long time, so is there a command to check if the garbage collection was triggered by using SOS.dll or SOSEX?

m_d_p29
  • 163
  • 8
  • why not run memprofiler on the code? – Mitch Wheat Jun 14 '15 at 03:43
  • You can start by looking at `!RootObjects` rather then triggered collections. – Yuval Itzchakov Jun 14 '15 at 04:58
  • @YuvalItzchakov: okay, so how can this help me understand if there was a collection triggered? – m_d_p29 Jun 14 '15 at 14:44
  • 1 - What do you mean by "triggered"? Like, ever? Or do want to know if it is in the middle of a GC? 2 - Why do you want to know this? 3 - How do you know objects are staying in memory for a "long time"? – Steve Johnson Jun 16 '15 at 02:35
  • @SteveJohnson: When I look at the dump, I see a particular object staying in generation 2 almost occupying 500+ MB, so I wanted to check if the garbage collection ran or not. – m_d_p29 Jun 24 '15 at 09:04
  • @m_d_p29 If that's what you care about, then just check whether that object is rooted or not. If it's not, then you know there hasn't been a full GC since that object became unrooted. – Sasha Goldshtein Jul 23 '15 at 07:46

1 Answers1

0

In a comment you mention

When I look at the dump, I see a particular object staying in generation 2 almost occupying 500+ MB, so I wanted to check if the garbage collection ran or not.

If you have an object in Gen 2, then garbage collection ran at least 2 times, otherwise it would be in Gen 0.

Now that you know it, it's obvious that this information is not really helpful. You want to know why it remains in memory.

To find out which reference keeps the large object in memory, use the SOS command !gcroot. When you know that, review your code to find out where such a reference comes from or where it should be removed.

If there is no reference any more, the object may be freed soon and it's just alive because no Gen 2 garbage collection has occurred since. See this great answer on IDisposable, which discusses the point of releasing a large object.

In your case, it might even be ok to call GC.Collect() after releasing the reference. Usually you should not tamper with garbage collection, but if you always have such a large object and you certainly know that this object is no longer needed and GC.Collect() resolves the OOM exception, then it is the right thing to do.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222