我有一个.Net应用程序(Windows服务),运行一段时间后,它消耗了很多非托管内存,直到它崩溃为止OutOfMemoryException
。此问题的更多信息(已删除;仅10k用户)。
我设法创建了一个Supervisor程序来扫描该应用程序的资源消耗,使用VMMap拍摄内存常规内存快照,并VirtualAlloc()
通过使用以下命令(为便于阅读而设置格式)在该函数处设置一个断点:
bp KERNELBASE!VirtualAlloc ".if (@rdx>=0x2FAF080) {
.printf \"============Allocating %lu bytes ================\n\", @rdx;
kb 8; !clrstack; gc
} .else{gc}"
但是WinDBG的输出显示了一些奇怪的值,并且我无法跟踪VMMap显示的相同分配,因此我认为RDX
(source)是条件断点上的一个错误寄存器。
我需要设置一个正确的断点以跟踪该非托管内存分配和stacktrace,最后找到有罪代码。
更新:这是本机堆栈的断点输出示例。我认为此处显示的字节不正确,因为VMMap没有显示该大小(3.6GB)的任何分配。令人奇怪的是,该字节值作为倒数第二个最后一个堆栈帧上显示clr!CExecutionEngine::ClrVirtualAlloc
(请参阅d8040000值)。
============Allocating 3624140800 bytes ================
RetAddr : Args to Child : Call Site
00007ffe`5844395a : 00000001`111bf000 00000000`d2cb8000 00000000`00a229da 00000000`5ff17000 : KERNELBASE!VirtualAlloc
00007ffe`584adf14 : 00000000`00000004 00000000`00000000 00000000`d8040000 00000051`000fcbf0 : clr!CExecutionEngine::ClrVirtualAlloc+0x4a
00007ffe`589da6c7 : 00000000`00000000 00000000`00100000 00000051`80490000 00000051`000fcbf0 : clr!ClrVirtualAlloc+0x3c
00007ffe`589da270 : 00000000`00000000 00000051`000fcdc8 00000051`80490000 00000000`0006e120 : clr!WKS::gc_heap::grow_brick_card_tables+0x177
00007ffe`589d9ee4 : 00000000`08000000 00000000`00000023 00000000`00000000 ffffffff`fffffff8 : clr!WKS::gc_heap::get_segment+0x140
00007ffe`589dae9e : 00000000`08000000 00000000`00000000 00000051`000fcde0 00000051`000fcdb0 : clr!WKS::gc_heap::get_large_segment+0x204
00007ffe`58829226 : 00000000`0000000c 00000000`00000000 00000000`00000000 00000000`00000000 : clr!WKS::gc_heap::loh_get_new_seg+0x5e
00007ffe`585313b1 : 0000fffc`00000003 00000000`00000003 00000000`00000003 00000000`0006e138 : clr!WKS::gc_heap::allocate_large+0x2f8156
@ThomasWeller发表评论后,我猜断点确实是正确的。
关于内存问题,我已经与Microsoft支持部门联系,他们确实找到了一块内存,但全为零!不过,我还没有找到导致这种现象的具体原因。
由于此问题的主要主题是关于断点准确性的问题,因此我现在关闭此主题。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句