调查内存泄漏 [英] Investigating Memory Leak

问题描述

我们在我们的应用程序中有一个缓慢的内存泄漏，我已经通过以下步骤尝试分析泄漏的原因：

1. 在GFlags中启用用户模式堆栈跟踪数据库


2. 在Windbg中，键入以下命令：！heap -stat -h 1250000 （其中1250000是有泄漏的堆的地址）
   比较多个转储后，我看到大小为 0xC 的内存块随着时间的推移而增加，可能是泄漏的内存。 >
   
3. 输入以下命令：！heap -flt sc
   给出这些分配的UserPtr，最后：


4. 打字其中一些地址上的！heap -p -a address 始终显示以下分配调用堆栈：

0：000> ！堆-p -a 10576ef8

 地址10576ef8在
中找到_HEAP @ 1250000 
 HEAP_ENTRY大小Prev Flags Us erPtr UserSize  -  state 
 10576ed0 000a 0000 [03] 10576ef8 0000c  - （busy）
 mscoreei！CLRRuntimeInfoImpl ::`vftable'
 7c94b244 ntdll！RtlAllocateHeapSlowly + 0x00000044 
 7c919c0c ntdll！RtlAllocateHeap + 0x00000e64 
 603b14a4 mscoreei！UtilExecutionEngine :: ClrHeapAlloc + 0x00000014 
 603b14cb mscoreei！ClrHeapAlloc + 0x00000023 
 603b14f7 mscoreei！ClrAllocInProcessHeapBootstrap + 0x0000002e 
 603b1614 mscoreei！operator new [] + 0x0000002b 
 603d402b + 0x0000005f 
 603d5142 mscoreei！GetThunkUseState + 0x00000025 
 603d6fe8 mscoreei！_CorDllMain + 0x00000056 
 79015012 mscoree！ShellShim__CorDllMain + 0x000000ad 
 7c90118a ntdll！LdrpCallInitRoutine + 0x00000014 
 7c919a6d ntdll！LdrpInitializeThread + 0x000000c0 
 7c9198e6 ntdll！_LdrpInitialize + 0x00000219 
 7c90e457 ntdll！KiUserApcDispatcher + 0x00000007 
  

这看起来像线程初始化调用堆栈，但我需要kno不止这个
下一步你会建议做什么来把手指放在确切的原因导致泄漏。

解决方案

使用GFlags时记录的堆栈是在不使用.pdb并且通常不正确的情况下完成的。
由于您已经将漏洞跟踪到给定堆上的特定大小，您可以尝试
在RtlAllocateHeap中设置实时中断，并使用适当的符号检查windbg中的堆栈。我已经使用了以下一些成功。您必须编辑它以适合您的堆和大小。

  $$显示堆栈，如果堆处理eq 0x00310000，大小为0x1303 
 $$ ============================================ $（$（@ esp + 4）= 0x00310000）&（poi（@ esp + c）= 0x1303））'k';'gc'
  

堆栈和其他想法为罪犯。

We have a slow memory leak in our application and I've already gone through the following steps in trying to analyize the cause for the leak:

1. Enabling user mode stack trace database in GFlags
2. In Windbg, typing the following command: !heap -stat -h 1250000 (where 1250000 is the address of the heap that has the leak) After comparing multiple dumps, I see that a memory blocks of size 0xC are increasing over time and are probably the memory that is leaked.
3. typing the following command: !heap -flt s c gives the UserPtr of those allocations and finally:
4. typing !heap -p -a address on some of those addresses always shows the following allocation call stack:

0:000> !heap -p -a 10576ef8

address 10576ef8 found in
_HEAP @ 1250000
  HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
    10576ed0 000a 0000  [03]   10576ef8    0000c - (busy)
    mscoreei!CLRRuntimeInfoImpl::`vftable'
    7c94b244 ntdll!RtlAllocateHeapSlowly+0x00000044
    7c919c0c ntdll!RtlAllocateHeap+0x00000e64
    603b14a4 mscoreei!UtilExecutionEngine::ClrHeapAlloc+0x00000014
    603b14cb mscoreei!ClrHeapAlloc+0x00000023
    603b14f7 mscoreei!ClrAllocInProcessHeapBootstrap+0x0000002e
    603b1614 mscoreei!operator new[]+0x0000002b
    603d402b +0x0000005f
    603d5142 mscoreei!GetThunkUseState+0x00000025
    603d6fe8 mscoreei!_CorDllMain+0x00000056
    79015012 mscoree!ShellShim__CorDllMain+0x000000ad
    7c90118a ntdll!LdrpCallInitRoutine+0x00000014
    7c919a6d ntdll!LdrpInitializeThread+0x000000c0
    7c9198e6 ntdll!_LdrpInitialize+0x00000219
    7c90e457 ntdll!KiUserApcDispatcher+0x00000007

This looks like thread initialization call stack but I need to know more than this. What is the next step you would recommend to do in order to put the finger at the exact cause for the leak.

解决方案

The stack recorded when using GFlags is done without utilizing .pdb and often not correct. Since you have traced the leak down to a specific size on a given heap, you can try to set a live break in RtlAllocateHeap and inspect the stack in windbg with proper symbols. I have used the following with some success. You must edit it to suit your heap and size.

 $$ Display stack if heap handle eq 0x00310000 and size is  0x1303
 $$ ====================================================================
bp ntdll!RtlAllocateHeap "j ((poi(@esp+4) = 0x00310000) & (poi(@esp+c) = 0x1303) )'k';'gc'" 

Maybe you then get another stack and other ideas for the offender.

这篇关于调查内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！