【问题标题】:native memory leak - how to find callstack of allocation source本机内存泄漏 - 如何找到分配源的调用堆栈
【发布时间】:2011-12-14 03:53:50
【问题描述】:

根据 !address -summary 命令的以下输出,我认为我遇到了本机内存泄漏。为了确定这些分配发生在哪里的调用堆栈,我正在关注http://www.codeproject.com/KB/cpp/MemoryLeak.aspx 的文章

0:000> !address -summary  
 TEB 7efdd000 in range 7efdb000 7efde000  
 TEB 7efda000 in range 7efd8000 7efdb000  
 TEB 7efd7000 in range 7efd5000 7efd8000  
 TEB 7efaf000 in range 7efad000 7efb0000  
 TEB 7efac000 in range 7efaa000 7efad000  
 ProcessParametrs 00441b78 in range 00440000 00540000  
 Environment 004407f0 in range 00440000 00540000  

-------------------- Usage SUMMARY --------------------------  
    TotSize (      KB)   Pct(Tots) Pct(Busy)   Usage  
    551a000 (   87144) : 04.16%    14.59%    : RegionUsageIsVAD  
   5b8d3000 ( 1499980) : 71.53%    00.00%    : RegionUsageFree  
    2cc3000 (   45836) : 02.19%    07.68%    : RegionUsageImage  
     4ff000 (    5116) : 00.24%    00.86%    : RegionUsageStack  
          0 (       0) : 00.00%    00.00%    : RegionUsageTeb  
   1c040000 (  459008) : 21.89%    76.87%    : RegionUsageHeap  
          0 (       0) : 00.00%    00.00%    : RegionUsagePageHeap  
       1000 (       4) : 00.00%    00.00%    : RegionUsagePeb  
          0 (       0) : 00.00%    00.00%    : RegionUsageProcessParametrs  
          0 (       0) : 00.00%    00.00%    : RegionUsageEnvironmentBlock  
       Tot: 7fff0000 (2097088 KB) Busy: 2471d000 (597108 KB)  


0:000> !heap -s  
LFH Key                   : 0x7fdcf95f  
Termination on corruption : DISABLED  
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast   
                    (k)     (k)    (k)     (k) length      blocks cont. heap   
-----------------------------------------------------------------------------  
00440000 00000002  453568 436656 453568     62    54    32    0      0   LFH    
006b0000 00001002      64     16     64      4     2     1    0      0        
002b0000 00041002     256      4    256      2     1     1    0      0        
00620000 00001002      64     16     64      5     2     1    0      0        
00250000 00001002      64     16     64      4     2     1    0      0        
007d0000 00041002     256      4    256      0     1     1    0      0        
005c0000 00001002    1088    388   1088      7    17     2    0      0   LFH  
02070000 00041002     256      4    256      1     1     1    0      0        
02270000 00041002     256    144    256      0     1     1    0      0   LFH  
04e10000 00001002    3136   1764   3136    384    36     3    0      0   LFH  
    External fragmentation  21 % (36 free blocks)  
-----------------------------------------------------------------------------  

但是当我运行 !heap -p –a 命令时,我没有得到任何调用堆栈,只有以下。任何想法如何获取分配源的调用堆栈?

0:000> !heap -p -a 0218e008  
    address 0218e008 found in  
    _HEAP @ 4e10000  
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state  
        0218e000 001c 0000  [00]   0218e008    000d4 - (busy)  

【问题讨论】:

    标签: windows memory-leaks windbg


    【解决方案1】:

    你应该使用deleaker。它是强大的调试工具。

    【讨论】:

      【解决方案2】:

      linux 使用 valgrind,windows 使用 deleaker。

      【讨论】:

        【解决方案3】:

        如果您没有从!heap -p -a 获得调用堆栈
        原因可能是您没有正确使用 gflags
        请记住使用正确的名称,包括 .exe
        尝试以交互方式启动它并转到图像选项卡,可能会更容易
        尝试使用页面堆,这也给出了调用堆栈

        【讨论】:

        • 我刚刚将windbg附加到实时进程并开始运行命令。在这种情况下我是否也需要运行 gflags?
        • 是的,在您启动 .exe 之前需要使用 gflags
        【解决方案4】:

        我对 Windows 一无所知,但至少在 Unix 系统上,调试器(如 Linux 上的 gdb)有助于理解调用堆栈。

        您还可以通过使用例如规避一些问题。 Boehm's conservative garbage collector。在许多系统上,您还可以在 valgrind 的帮助下寻找内存泄漏

        【讨论】:

        • windbg 是 Windows 上的“所有调试器之母”。如对codeproject文章的参考所示,您似乎可以追查到它,我可能做错了什么。
        猜你喜欢
        • 1970-01-01
        • 2020-02-18
        • 2011-08-28
        • 2018-02-03
        • 2014-09-29
        • 1970-01-01
        • 2014-11-02
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多