CODEWITHSUNDEEP
memory-leaksout-of-memoryclrwindbgmemory-fragmentation
Chiune Sugihara
Chiune Sugihara

Reputation: 1229

Excessive Gen 2 Free Blocks in Crash Dump

On inspecting a crash dump file for an out of memory exception reported by a client the results of !DumpHeap -stat showed that 575MB of memory is being taken up by 45,000 objects of type "Free" most of which I assume would have to reside in Gen 2 due to the size.

The first places I looked for problems were the large object heap (LOH) and pinned objects. The large object heap with free space included was only 70MB so that wasn't the issue and running !gchandles showed:

GC Handle Statistics:
Strong Handles:        155
Pinned Handles:        265
Async Pinned Handles:  8
Ref Count Handles:     163
Weak Long Handles:     0
Weak Short Handles:    0
Other Handles:         0

which is a very small number of handles (around 600) compared to the number of free objects (45,000). To me this rules out the free blocks being caused by pinning.

I also looked into the free blocks themselves to see if maybe they had a consistent size, but on inspection the sizes varied widely and went from just short of 5MB to only around 12 bytes or so.

Any help would be appreciated! I am at a loss since there is fragmentation but no signs of it being cause by the two places that I know to look which are the large object heap (LOH) and pinned handles.

Upvotes: 4

Views: 823

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59513

In which generation are the free objects?

I assume would have to reside in Gen 2 due to the size

Size is not related to generations. To find out in which generation the free blocks reside, you can follow these steps:

From !dumpheap -stat -type Free get the method table:

0:003> !dumpheap -stat -type Free
total 7 objects
Statistics:
      MT    Count    TotalSize Class Name
00723538        7          100      Free
Total 7 objects

From !eeheap -gc, get the start addresses of the generations.

0:003> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x026a1018
generation 1 starts at 0x026a100c
generation 2 starts at 0x026a1000
ephemeral segment allocation context: none
 segment    begin allocated     size
026a0000 026a1000  02731ff4 0x00090ff4(593908)
Large object heap starts at 0x036a1000
 segment    begin allocated     size
036a0000 036a1000  036a3250 0x00002250(8784)
Total Size   0x93244(602692)
------------------------------
GC Heap Size   0x93244(602692)

Then dump the free objects only of a specific generation by passing the start and end address (e.g. of generation 2 here):

0:003> !dumpheap -mt 00723538 0x026a1000 0x026a100c
 Address       MT     Size
026a1000 00723538       12 Free
026a100c 00723538       12 Free
total 2 objects
Statistics:
      MT    Count    TotalSize Class Name
00723538        2           24      Free
Total 2 objects

So in my simple case, there are 2 free objects in generation 2.

Pinned handles

600 pinned objects should not cause 45.000 free memory blocks. Still from my experience, 600 pinned handles are a lot. But first, check in which generation the free memory blocks reside.

Upvotes: 1

Related Questions