为什么在! dumheap -stat中对象的总和不匹配!EEHeap -gc
本文关键字：不匹配 EEHeap -gc 对象 dumheap -stat 为什么 | 更新日期: 2023-09-27 18:19:25
我正在查看WinDbg中的完整应用程序转储，并试图了解我的内存在哪里被消耗。
我已经解析了!DumpHeap -stat的输出，并在此报告中总结了总内存，得到了~7 GB。相比之下，如果我运行!EEHeap -gc，它总共报告约11gb。
为什么这两个报告之间有这么大的差异?我怎样才能知道额外的4 GB在哪里?
!eeheap的值为. net分配的段大小之和。
该值总是大于!dumpheap的输出之和。在某些情况下，它差别很大，因为在某些段中只有几个对象，例如固定对象，用于本机PInvoke或COM互操作的东西。这会阻止。net释放这些段。您可以使用!gchandles检查固定对象。
将!eeheap的值与!address -summary报告的VitualAlloc()的本机代码，并且您不使用MSXML，那么!eeheap的值应该与此值接近。
我是。net团队的开发人员。我相信这可能是SOS的一个bug。对于eeheap，我们计算段大小的方法是使用段中最后一个对象的结束地址减去段的开始地址。然后把所有这些段的大小加在一起，得到堆的总大小。
这里是代码sos eeheap(https://github.com/dotnet/coreclr/blob/bc146608854d1db9cdbcc0b08029a87754e12b49/src/ToolBox/SOS/Strike/eeheap.cpp)，你可以看看GCPrintSegmentInfo, GCPrintLargeHeapSegmentInfo和GCHeapInfo。
有时，由于对象在段中对齐，段大小实际上不等于同一段中的总对象大小。DumpHeap也会过滤掉一些不存在的对象。这两个因素可能导致!DumpHeap列出的对象的总大小不等于!eeheap。但4GB似乎比平时要大。可能是bug。但是没有我可以玩的东西，我无法得出结论。
你可以使用connect向我们提交bug，我们会查看的。这是入侵https://connect.microsoft.com/IE/content/content.aspx?ContentID=29582。为了便于调查，如果你不介意的话，你能不能给我们发一个程序或者一个dump来重现你遇到的问题?这将有助于我们的调查。由于