了解对象在gc堆中的布局是很有用的。在垃圾收集期间，有效的对象是通过递归访问对象来标记的，这些对象从堆栈的根和句柄开始。但是，从每个堆段的开始到结束，对象的位置以一种有组织的方式排列也很重要。！DumpHeap命令依赖于这个逻辑组织来正确地遍历堆，如果它报告了一个错误，可以打赌您的堆出了问题。
下面是代码
using System; using System.Reflection; using System.Reflection.Emit; using System.Threading; using System.Runtime.InteropServices; public class EmitHelloWorld { [DllImport("kernel32")] public static extern void DebugBreak(); static void Main(string[] args) { // create a dynamic assembly and module AssemblyName assemblyName = new AssemblyName(); assemblyName.Name = "HelloWorld"; AssemblyBuilder assemblyBuilder = Thread.GetDomain().DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.RunAndSave); ModuleBuilder module; module = assemblyBuilder.DefineDynamicModule("HelloWorld.exe"); // create a new type to hold our Main method TypeBuilder typeBuilder = module.DefineType("HelloWorldType", TypeAttributes.Public | TypeAttributes.Class); // create the Main(string[] args) method MethodBuilder methodbuilder = typeBuilder.DefineMethod("Main", MethodAttributes.HideBySig | MethodAttributes.Static | MethodAttributes.Public, typeof(void), new Type[] { typeof(string[]) }); // generate the IL for the Main method ILGenerator ilGenerator = methodbuilder.GetILGenerator(); ilGenerator.EmitWriteLine("hello, world"); ilGenerator.Emit(OpCodes.Ret); // bake it Type helloWorldType = typeBuilder.CreateType(); // run it helloWorldType.GetMethod("Main").Invoke(null, new string[] {null}); DebugBreak(); // set the entry point for the application and save it assemblyBuilder.SetEntryPoint(methodbuilder, PEFileKinds.ConsoleApplication); assemblyBuilder.Save("HelloWorld.exe"); } }
将程序另存为example.cs，编译并运行“cdb-g示例.exe"
当您到达断点时，加载sos并运行“！eeheap-gc”。它列出了存储对象的堆段：
0:000> !eeheap -gc Number of GC Heaps: 1 generation 0 starts at 0x00aa1b78 generation 1 starts at 0x00a5100c generation 2 starts at 0x00a51000 ephemeral segment allocation context: none segment begin allocated size 00a50000 00a51000 00ae4000 0x00093000(602112) Large object heap starts at 0x01a51000 segment begin allocated size 01a50000 01a51000 01a54060 0x00003060(12384) Total Size 0x96060(614496) ------------------------------ GC Heap Size 0x96060(614496)
这是一个小的gc堆，只有一个普通对象段和一个大对象段（对于80K以上的对象）。对我们来说没问题。正常大小的对象从地址00a51000开始，到00ae4000结束。一般来说，我们有一个简单的模式：
|---------| segment.begin = 00a51000
|object 1 |
|_________|
|object 2 |
|_________|
| ... |
|_________|
|object N |
|_________| segment.allocated = 00ae4000
每个对象有多大？你可以运行！dumpobj就知道。有趣的是，每个对象都有一个4字节的头，对象2的头大小包含在对象1的大小中。另一点是堆中存在一种称为“Free”对象的特殊类型的对象。这是用来填补有效对象之间的洞。这些自由对象是临时的，因为如果发生压缩gc，它们将消失。
我们开始走吧。
0:000> !dumpobj 00a51000 Free Object Size 12(0xc) bytes 0:000> !dumpobj 00a51000+c Free Object Size 12(0xc) bytes 0:000> !dumpobj 00a51000+c+c Free Object Size 12(0xc) bytes 0:000> !dumpobj 00a51000+c+c+c Name: System.OutOfMemoryException MethodTable: 03077e9c EEClass: 03064050 Size: 68(0x44) bytes (C:WINDOWSMicrosoft.NETFrameworkv2.0.x86dbgmscorlib.dll) Fields: MT Field Offset Type Attr Value Name 03076b7c 40000a5 4 CLASS instance 00000000 _className 03076b7c 40000a6 8 CLASS instance 00000000 _exceptionMe thod 03076b7c 40000a7 c CLASS instance 00000000 _exceptionMe thodString 03076b7c 40000a8 10 CLASS instance 00000000 _message 03076b7c 40000a9 14 CLASS instance 00000000 _data 03076b7c 40000aa 18 CLASS instance 00000000 _innerExcept ion 03076b7c 40000ab 1c CLASS instance 00000000 _helpURL 03076b7c 40000ac 20 CLASS instance 00000000 _stackTrace 03076b7c 40000ad 24 CLASS instance 00000000 _stackTraceS tring 03076b7c 40000ae 28 CLASS instance 00000000 _remoteStack TraceString 03076b7c 40000af 30 System.Int32 instance 0 _remoteStack Index 03076b7c 40000b0 34 System.Int32 instance -2147024882 _HResult 03076b7c 40000b1 2c CLASS instance 00000000 _source 03076b7c 40000b2 38 System.IntPtr instance 0 _xptrs 03076b7c 40000b3 3c System.Int32 instance -532459699 _xcode
哇，花了点时间才找到有趣的东西。你可以继续这样，直到你得到一个缓冲区溢出，因为所有“+c+44+68+12+…”你也可以让!DumpHeap帮你做这个。它给出了一个相当稀疏的printers对象。让我们将输出限制在我们关心的段（注意大小是十进制）：
0:000> !dumpheap 00a51000 00ae4000 Address MT Size 00a51000 0015c260 12 Free 00a5100c 0015c260 12 Free 00a51018 0015c260 12 Free 00a51024 03077e9c 68 00a51068 030782cc 68 00a510ac 030786fc 68 00a510f0 03078b5c 68 00a51134 030f7b54 20 00a51148 0308b06c 108 00a511b4 030fa5bc 32 00a511d4 0305bbf8 28 00a511f0 030592e0 80 00a51240 0015c260 72 Free ...
我们怎么知道每个物体的大小？看看MethodTable，对象的第一个DWORD。你可以在上面运行!dumpmt：
0:000> !dumpmt 03077e9c EEClass: 03064050 Module: 0016b118 Name: System.OutOfMemoryException mdToken: 02000038 (C:WINDOWSMicrosoft.NETFrameworkv2.0.x86dbgmscorlib.dll) BaseSize: 44 Number of IFaces in IFaceMap: 2 Slots in VTable: 21
这里的BaseSize是十六进制的。数组呢，我们怎么知道它们的大小？让我们列出该段中的所有数组来计算：
0:000> !dumpheap -type [] 00a51000 00ae4000 Address MT Size 00a511f0 030592e0 80 00a5129c 03115b68 56 00a51348 03135ca0 76 00a513a8 030592e0 16 00a51434 0313b1c0 144 00a51634 0313c234 100 00a51698 0313c620 56 00a51cc4 030592e0 16 00a51e8c 0313b1c0 144 00a52008 0313b1c0 144 00a52244 0313b1c0 144 00a52308 0313b1c0 144 00a523cc 0313b1c0 144 00a52620 0313b1c0 144 00a526e4 0313b1c0 144 00a52a14 031e23f8 36 00a52b7c 0313b1c0 144 00a52c0c 0315778c 1084 00a53048 0315778c 1628 00a536a4 0315778c 824 ...
随机挑选一个：
0:000> !dumpobj 00a52c0c Name: System.Int32[] MethodTable: 0315778c EEClass: 03157708 Size: 1084(0x43c) bytes Array: Rank 1, Type Int32 Element Type: System.Int32 Fields: None
确定数组大小的公式为：
MethodTable.BaseSize + (MethodTable.ComponentSize * Object.Components)
!dumpmt会告诉你前两个：
0:000> !dumpmt 315778c EEClass: 03157708 Module: 0016b118 Name: System.Int32[] mdToken: 02000000 (C:WINDOWSMicrosoft.NETFrameworkv2.0.x86dbgmscorlib.dll) BaseSize: 0xc ComponentSize: 0x4 Number of IFaces in IFaceMap: 4 Slots in VTable: 25
您可以通过以下方式找到数组中的项数：
0:000> dd 00a52c0c+4 l1 00a52c10 0000010C 0:000>
所以我们了解物体的大小，以及它们是如何排列的。但是有一件事遗漏了，这就是在整个堆中存在称为分配上下文的零填充区域。为了提高效率，可以为每个托管线程指定这样一个区域，以便将新的分配定向到该区域。这允许多线程应用程序在没有昂贵的锁定操作的情况下进行分配。对于包含第0代和第1代的堆段（也称为临时段），还有一个分配上下文。这个!dumpheap命令知道这些区域，并在它们上面轻轻地执行步骤。您可以使用获取线程分配上下文地址!thread命令：
0:000> !threads ThreadCount: 2 UnstartedThread: 0 BackgroundThread: 1 PendingThread: 0 DeadThread: 0 PreEmptive GC Alloc Lock ID OSID ThreadOBJ State GC Context Domain Count APT Exception 0 1 16ac 00155da8 a020 Enabled 00ae2e1c:00ae3ff4 0014a890 0 MTA 2 2 169c 001648f8 b220 Enabled 00000000:00000000 0014a890 0 MTA (Finalizer)
线程0（主线程）具有从00ae2e1c到00ae3ff4的分配上下文。如果我们看一下内存，我们会看到所有的零：
0:000> dd 00ae2e1c 00ae2e1c 00000000 00000000 00000000 00000000 00ae2e2c 00000000 00000000 00000000 00000000 00ae2e3c 00000000 00000000 00000000 00000000 00ae2e4c ...
至于短暂的段分配上下文，我们没有。看下！eeheap-gc输出：
0:000> !eeheap -gc Number of GC Heaps: 1 generation 0 starts at 0x00aa1b78 generation 1 starts at 0x00a5100c generation 2 starts at 0x00a51000 ephemeral segment allocation context: none segment begin allocated size 00a50000 00a51000 00ae4000 0x00093000(602112) ...
有一天可能会出现缓冲区溢出，并在StrongBad fan club成员数组之后删除对象的MethodTable。下一次GC发生时，您的程序将崩溃。让我们模拟一下那可怕的发生，看看怎么办！dumpheap输出：
0:000> ed adf7f8 00650033 (I'm overwriting the MethodTable of the array we've been enjoying) 0:000> !dumpheap 00a51000 00ae4000 ... 00adf7ac 03135ca0 76 object 00adf7f8: does not have valid MT curr_object : 00adf7f8 Last good object: 00adf7ac
这会让你对最后一个好东西，00adf7ac产生怀疑。我们当然知道他没事，他对发生的事情不负责任。但在现实世界中，需要积极的回应！
最后的好东西是什么？
0:000> !dumpobj adf7ac Name: System.Byte[] MethodTable: 03135ca0 EEClass: 03135c1c Size: 76(0x4c) bytes Array: Rank 1, Type Byte Element Type: System.Byte Fields: None
谁在乎他？如果我能在堆栈上找到这个对象的根，我可能接近覆盖下一个对象的代码：
0:000> !gcroot adf7ac Note: Roots found on stacks may be false positives. Run "!help gcroot" for more info. Scan Thread 0 OSTHread 16ac ESP:12ea9c:Root:00ad4914(System.Reflection.Emit.MethodBuilder)->00ad4448(System. Reflection.Emit.TypeBuilder)->00adf52c(System.Reflection.Emit.MethodBuilder)->00 adf74c(System.Reflection.Emit.ILGenerator)->00adf7ac(System.Byte[]) Scan Thread 2 OSTHread 169c
线程0，是吗？他受雇于ILGenerator，是吗？他们店里正在进行什么邪恶的行动！好吧，我停下来。但这是真的，最后一个好的对象通常是有责任的，而PInvoke溢出就是原因。