Managed Memory Leak will be reported by an OutOfMemoryException exception thrown by the CLR. There are a few reasons will result in it.
1) Too many objects are alive.
2) Object handle leak. Use !sos.objsize to list handles.
3) Heap fragmentation. Use !sos.dumpheap to get excessive GC Heap fragmentation report.
When you debug the code, very oftern you need to deal with memory and registers. It would be beneficial to understand the eight general-purpose registers in the x86 processor family. Each register has a unique purpose and has special instructions and opcodes which make fulfilling this purpose more convenient or efficient. The registers and their uses are shown briefly below:
- EAX - Accumulator register.
- EDX - The data register is the an extension to the accumulator. It is most useful for storing data related to the accumulator’s current calculation.
- ECX - The count register.
- EDI - Every loop must store its result somewhere, and the destination index points to that place. With a single-byte STOS instruction to write data out of the accumulator, this register makes data operations much more size-efficient.
- ESI - In loops that process data, the source index holds the location of the input data stream. Like the destination index, ESI had a convenient one-byte instruction for loading data out of memory into the accumulator.
- ESP - ESP is the stack pointer. Its value is required by PUSH, POP, CALL, and RET instructions.
- EBP - In functions that store parameters or variables on the stack, the base pointer holds the location of the current stack frame. In other situations, however, EBP is a free data-storage register.
- EBX - In 16-bit mode, the base register was useful as a pointer. Now it is completely free for extra storage space.
You can use Debugging Tools for Windows to debug drivers, applications, and services on systems that are running Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008. You can also use Debugging Tools for Windows to debug the operating system itself. Versions of the Debugging Tools for Windows package are available for 32-bit x86, native Intel Itanium, and native x64 platforms.
The latest release of Debugging Tools for Windows is available for download (see the Using Debugging Tools for Windows section on this page). You can also install the package from the Windows Driver Kit (WDK), the Platform SDK, or a Customer Support Diagnostics CD.
Note: If you have a system with a 64-bit processor and you are debugging an application on it, you must use one of the native 64-bit packages.
Download the right tools from MSDN.
-Run windbg.exe or cdb.exe
>.hh [keyword] for help
Every Object is preceded by an object header -ObjHeader (at a negative offset). ObjHeader is a DWORD and has a combination of different bit masks (defined in Syncblk.h) like hash code, AppDomain index, flags to facility string operations, thin lock bit and etc.
When the DWORD is not large enough, CLR will create a SyncBlock for the object and set the SyncBlock index in object header.
CLR Object Internal - from Shared Source CLI Essentials
Every Object is preceded by an ObjHeader (at a negative offset). The ObjHeader has an index to a SyncBlock. This index is 0 for the bulk of all instances, which indicates that the object shares a dummy SyncBlock with most other objects. All SyncBlocks are stored in SyncTable as an array and managed by SyncBlockCache.
The SyncBlock is primarily responsible for object synchronization. However, it is also a “kitchen sink” of sparsely allocated instance data. For instance, the default implementation of Hash() is based on the existence of a SyncTableEntry. And objects exposed to or from COM, or through context boundaries, can store sparse data here.
SyncTableEntries and SyncBlocks are allocated in non-GC memory. A weak pointer from the SyncTableEntry to the instance is used to ensure that the SyncBlock and SyncTableEntry are reclaimed (recycled) when the instance dies.
The organization of the SyncBlocks isn’t intuitive (at least to me). Here’s the explanation:
Before each Object is an ObjHeader. If the object has a SyncBlock, the ObjHeader contains a non-0 index to it.
The index is looked up in the g_pSyncTable of SyncTableEntries. This means the table is consecutive for all outstanding indices. Whenever it needs to grow, it doubles in size and copies all the original entries. The old table is kept until GC time, when it can be safely discarded.
Each SyncTableEntry has a backpointer to the object and a forward pointer to the actual SyncBlock. The SyncBlock is allocated out of a SyncBlockArray which is essentially just a block of SyncBlocks.
The SyncBlockArrays are managed by a SyncBlockCache that handles the actual allocations and frees of the blocks.
Each allocation and release has to handle free lists in the table of entries and the table of blocks.
We burn an extra 4 bytes for the pointer from the SyncTableEntry to the SyncBlock.
The reason for this is that many objects have a SyncTableEntry but no SyncBlock. That’s because someone (e.g. HashTable) called Hash() on them.
- syncblk.h
An object’s CLR internal structure is:
[DWORD: SyncBlock][DWORD: MethodTable Pointer][DWORD: Reference type pointer]…[Value of Value Type field]…
Object Header: [DWORD: SyncBlock]
Object Pointer: [DWORD: MethodTable Pointer][DWORD: Reference type pointer]…[Value of Value Type field]…
Every Object is preceded by an ObjHeader (at a negative offset). The ObjHeader has an index to a SyncBlock.
Sample C# code for exploring CLR object’s internal structure
namespace ObjectInternal
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
class Program
{
static void Main(string[] args)
{
Product p = new Product();
p.Price = 99;
p.Index = 25;
p.Name = "Super Product";
p.Cat = new Cateogry();
}
}
class Product
{
public int Price { get; set; }
public byte Index { get; set; }
public string Name { get; set; }
public Cateogry Cat { get; set; }
}
public class Cateogry
{
public string Name;
}
}
Sample output from SOS.dll debugger extension:
.load sos
extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded
!dumpstackobjects
PDB symbol for mscorwks.dll not loaded
OS Thread Id: 0xbb4 (2996)
ESP/REG Object Name
0012f0d4 012c2c10 System.Object[] (System.String[])
0012f20c 012c2c10 System.Object[] (System.String[])
0012f218 012c2c4c ObjectInternal.Product
0012f21c 012c2c64 ObjectInternal.Cateogry
0012f438 012c2c64 ObjectInternal.Cateogry
0012f43c 012c2c4c ObjectInternal.Product
0012f440 012c2c4c ObjectInternal.Product
0012f444 012c2c10 System.Object[] (System.String[])
0012f534 012c2c10 System.Object[] (System.String[])
0012f6e0 012c2c10 System.Object[] (System.String[])
0012f708 012c2c10 System.Object[] (System.String[])
!dumpobj 012c2c4c
Name: ObjectInternal.Product
MethodTable: 00933138
EEClass: 00931384
Size: 24(0x18) bytes
(C:\temp\ObjectInternal\ObjectInternal\bin\Debug\ObjectInternal.exe)
Fields:
MT Field Offset Type VT Attr Value Name
79332c4c 4000001 c System.Int32 1 instance 99 <Price>k__BackingField
79333520 4000002 10 System.Byte 1 instance 25 <Index>k__BackingField
79330a00 4000003 4 System.String 0 instance 012c2c20 <Name>k__BackingField
009331b0 4000004 8 ...Internal.Cateogry 0 instance 012c2c64 <Cat>k__BackingField
!dumpobj 012c2c20
Name: System.String
MethodTable: 79330a00
EEClass: 790ed64c
Size: 44(0x2c) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: Super Product
Fields:
MT Field Offset Type VT Attr Value Name
79332c4c 4000096 4 System.Int32 1 instance 14 m_arrayLength
79332c4c 4000097 8 System.Int32 1 instance 13 m_stringLength
793316e0 4000098 c System.Char 1 instance 53 m_firstChar
79330a00 4000099 10 System.String 0 shared static Empty
>> Domain:Value 0015d370:012c1198 <<
79331630 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 0015d370:012c1790 <<
Physical memory layout of CLR objects:
CLR Object's Internal Structure
We use !dumpobj to examine Product object instance, which is located at address: 0×012c2c4c. You can see that: field Name(String “Super Product”)’s address is 0×012c2c20, MethodTable is 0×79330a00. Field Cateogry’s address is 0×012c2c64 and MethodTable is 0×009331b0. Value types are directly stored as 0×63(99) and 0×19(25).
You can use !DumpStackObjects and !DumpObj to explore an object’s internal structure.
CLR Internal - string object's internal structure
A string object’s CLR internal structure is:
[DWORD: SyncBlock][DWORD: MethodTable Pointer][DWORD: length as array][DWORD: length as string][WCHAR: 1st char]…[WCHAR: NULL]
From above screenshot, you can see that the SyncBlock: 80000000 Method table pointer is: 79330a00, m_arrayLength: 9, m_stringLength: 8, m_firstChar, …
!dumpobj 012c2b2c
Name: System.String
MethodTable: 79330a00
EEClass: 790ed64c
Size: 34(0x22) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: abcdefgh
Fields:
MT Field Offset Type VT Attr Value Name
79332c4c 4000096 4 System.Int32 1 instance 9 m_arrayLength
79332c4c 4000097 8 System.Int32 1 instance 8 m_stringLength
793316e0 4000098 c System.Char 1 instance 61 m_firstChar
79330a00 4000099 10 System.String 0 shared static Empty
>> Domain:Value 0015d318:012c1198 <<
79331630 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 0015d318:012c1774 <<
[-start <startIndex>] [-length <length>] [-details] [-nofields] <array object address>
This command allows you to examine elements of an array object. The arguments in detail:
-start <startIndex>: optional, only supported for single dimension array. Specify from which index the command shows the elements.
-length <length>: optional, only supported for single dimension array. Specify how many elements to show.
-details: optional. Ask the command to print out details of the element using !DumpObj and !DumpVC format.
-nofields: optional, only takes effect when -detail is used. Do not print fields of the elements. Useful for array of objects like String.
CLR Object MethodTable EEClass Relationship
Object is the building block in the managed world.
Debugging Commands: !DumpObj, !DumpStackObjects, !DumpArray
A type describes fields and properties that hold data, as well as methods and events that describe its behavior. The information stored in a type can include the following:
- The storage space that a variable of the type requires.
- The maximum and minimum values that it can represent.
- The members (methods, fields, events, and so on) that it contains.
- The base type it inherits from.
- The location where the memory for variables will be allocated at run time.
- The kinds of operations that are permitted.
EEClass is the data structure used by CLR to store all information about a Type.
A MethodTable contains an array of structures that describes each interface implemented by the class (directly declared or indirectly declared).
Generic type instantiations (in C# syntax: C<ty_1,…,ty_n>) are represented by MethodTables, i.e. a new MethodTable gets allocated for each such instantiation. The entries in these tables (i.e. the code) are, however, often shared.
Method descriptor is a data structure used to store important information for a single method.
!GCHandles provides statistics about GCHandles in the process. Sometimes the source of a memory leak is a GCHandle leak. For example, code might keep a 50 Megabyte array alive because a strong GCHandle points to it, and the handle was discarded without freeing it.
The most common handles are “Strong Handles,” which keep the object they point to alive until the handle is explicitly freed. “Pinned Handles” are used to prevent the garbage collector from moving an object during collection. These should be used sparingly, and for short periods of time. If you don’t follow that precept, the gc heap can become very fragmented.
If you run with the -perdomain option, you will get the same output broken down by AppDomain. Here is sample output from a very simple program:
!GCHandles
GC Handle Statistics:
Strong Handles: 15
Pinned Handles: 4
Async Pinned Handles: 0
Ref Count Handles: 0
Weak Long Handles: 0
Weak Short Handles: 1
Other Handles: 0
Statistics:
MT Count TotalSize Class Name
7933061c 1 12 System.Object
793310cc 1 28 System.SharedStatics
79331f4c 2 48 System.Reflection.Assembly
79330d44 1 72 System.ExecutionEngineException
79330cb4 1 72 System.StackOverflowException
79330c24 1 72 System.OutOfMemoryException
793311e0 1 100 System.AppDomain
79330fd4 2 112 System.Threading.Thread
793326c4 4 144 System.Security.PermissionSet
79330dd4 2 144 System.Threading.ThreadAbortException
793041d0 4 8736 System.Object[]
Total 20 objects
This command is an aid in tracking down GCHandle leaks. It searches all of memory for any references to the Strong and Pinned GCHandles in the process, and reports what it found. If a handle is found, you’ll see the address of the reference. This might be a stack address or a field within an object, for example. If a handle is not found in memory, you’ll get notification of that too.
The command has diagnostic output which doesn’t need to be repeated here. One thing to keep in mind is that anytime you search all of memory for a value, you can get false positives because even though the value was found, it might be garbage in that no code knows about the address. You can also get false negatives because a user is free to pass that GCHandle to unmanaged code that might store the handle in a strange way (shifting bits, for example). For example, a GCHandle valuetype is stored on the stack with the low bit set if it points to a Pinned handle. So !GCHandleLeaks ignores the low bit in it’s searches.
That said, if a serious leak is going on, you’ll get a ever-growing set of handle addresses that couldn’t be found.
!gchandleleaks ------------------------------------------------------------------------------- GCHandleLeaks will report any GCHandles that couldn't be found in memory. Strong and Pinned GCHandles are reported at this time. You can safely abort the memory scan with Control-C or Control-Break. ------------------------------------------------------------------------------- Found 19 handles: 009111a8 009111ac 009111b4 009111bc 009111c0 009111cc 009111d0 009111d4 009111d8 009111dc 009111e0 009111e4 009111e8 009111f8 009111fc 009113f0 009113f4 009113f8 009113fc Searching memory Reference found in stress log will be ignored Error during command: Warning. Extension is using a callback which Visual Studio does not implement. ------------------------------------------------------------------------------ Some handles were not found. If the number of not-found handles grows over the lifetime of your application, you may have a GCHandle leak. This will cause the GC Heap to grow larger as objects are being kept alive, referenced only by the orphaned handle. If the number doesn't grow over time, note that there may be some noise in this output, as an unmanaged application may be storing the handle in a non-standard way, perhaps with some bits flipped. The memory scan wouldn't be able to find those. ------------------------------------------------------------------------------ Didn't find 19 handles: 009111a8 009111ac 009111b4 009111bc 009111c0 009111cc 009111d0 009111d4 009111d8 009111dc 009111e0 009111e4 009111e8 009111f8 009111fc 009113f0 009113f4 009113f8 009113fc
©2009 NetInverse. All rights reserved. Powered by WordPress