基于WinDbg的内存泄漏分析

在前面C++中基于Crt的内存泄漏检测一 文中提到的方法已经可以解决我们的大部分内存泄露问题了，但是该方法是有前提的，那就是一定要有源代码，而且还只能是Debug版本调试模式下。实际上很 多时候我们的程序会用到第三方没有源代码的模块，有些情况下我们甚至怀疑系统模块有内存泄露，但是有没有证据，我们该怎么办？ 这时我们就要依靠无所不能的WinDbg了。

WinDbg的!heap命令非常强大，结合AppVerifier可以对堆(heap)内存进行详细的跟踪和分析， 我们接下来对下面的代码进行内存泄漏的分析：

// MemLeakTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <Windows.h>
#include <stdio.h>

int _tmain(int argc, _TCHAR* argv[])
{
    char* p1 = new char;
    printf("%p\n", p1);

char* pLargeMem = new char[40000];

for(int i=0; i<1000; ++i)
    {
        char* p = new char[20];
    }
    
    system("pause");

return 0;
}

首先下载安装AppVerifier， 可到这里下载， 把我们需要测试的程序添加到AppVerifier的检测列表中， 然后保存。

注: 我们这里用AppVerifier主要是为了打开页堆(page heap)调试功能，你也可以用系统工具 gflags.exe 来做同样的事。

双击运行我们要调试的MemLeakTest.exe, 效果如下：

然后将WinDbg Attach上去， 输入命令 !heap -p -a 0x02FC1FF8，结果如下：

0:001> !heap -p -a 0x02FC1FF8
    address 02fc1ff8 found in
    _DPH_HEAP_ROOT @ 2f01000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 2f02548:          2fc1ff8                1 -          2fc1000             2000
    5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
    77447e5e ntdll!RtlpAllocateHeap+0x000000c4
    774134df ntdll!RtlAllocateHeap+0x0000023a
    5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
    5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
    72893db8 MSVCR90!malloc+0x00000079
    72893eb8 MSVCR90!operator new+0x0000001f
    012c1008 MemLeakTest!wmain+0x00000008 [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 11]
    77331114 kernel32!BaseThreadInitThunk+0x0000000e
    7741b429 ntdll!__RtlUserThreadStart+0x00000070
    7741b3fc ntdll!_RtlUserThreadStart+0x0000001b

怎么样， 神奇吧？我们当分配该地址内存时的堆栈(stack)被完整地打印了出来。

当然有人很快会说：这是你知道内存地址的情况， 很多情况下我们是不知道该地址的，该如何分析？

对
于这种情况， 我们首先需要明确一些概念， 我们new出来的内存是分配在堆上， 那一个进程里究竟有多少个堆，
每个模块都有自己单独的堆吗？实际上一个进程可以有任意多个堆，我们可以通过CreateHeap创建自己单独的堆，
然后通过HeapAlloc分配内存。 我们new出来的内存是crt(C运行库)分配的， 那就涉及到crt究竟有多少个堆了？
crt有多少个堆由你编译每个模块(Dll/Exe)时的编译选项决定， 如果你运行库选项用的是/MD, 那就和其他模块共享一个堆; 如果用/MT，
那就是自己单独的堆。大部分情况下我们会用/MD，这样我们在一个模块里new内存, 另一个模块里delete不会有问题， 因为大家共享一个堆。

明确这些概念之后， 我们看看我们的测试程序有多少个堆， 输入!heap -p

0:001> !heap -p

Active GlobalFlag bits:
        vrf - Enable application verifier
        hpa - Place heap allocations at ends of pages

StackTraceDataBase @ 00160000 of size 01000000 with 00000034 traces

PageHeap enabled with options:
        ENABLE_PAGE_HEAP
        COLLECT_STACK_TRACES

active heaps:

+ 1160000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 1300000
          HEAP_GROWABLE 
    + 1400000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 16b0000
          HEAP_GROWABLE HEAP_CLASS_1 
    + 2360000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 1280000
          HEAP_GROWABLE HEAP_CLASS_1 
    + 2f00000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 31d0000
          HEAP_GROWABLE HEAP_CLASS_1

可以看到我们的测试程序一共有4 个堆。

接下来我们的问题就是确定哪个是我们的crt堆， 也就是我们需要分析每个堆创建时的堆栈(stack)情况.

我们接下来分析最后一个堆， handle是2f00000， 输入!heap -p -h 02f00000 分析该堆的内存分配情况

0:001> !heap -p -h 02f00000
    _DPH_HEAP_ROOT @ 2f01000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
        02f01f04 : 02f09000 00002000
        02f02e38 : 02f69000 00002000
        037e2548 : 03892000 00002000
        037e2514 : 03894000 00002000
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
        02f01f6c : 02f05de8 00000214 - 02f05000 00002000
        02f01f38 : 02f07800 00000800 - 02f07000 00002000
        02f01ed0 : 02f0bde0 00000220 - 02f0b000 00002000
        02f01e9c : 02f0df50 000000ac - 02f0d000 00002000
        02f01e68 : 02f0ffe0 0000001f - 02f0f000 00002000
        02f01e34 : 02f11fd8 00000028 - 02f11000 00002000
        02f01e00 : 02f13fe0 0000001d - 02f13000 00002000
        02f01dcc : 02f15fc0 0000003a - 02f15000 00002000
        ....

可以看到该堆 _DPH_HEAP_ROOT 结构的地址是 2f01000，通过dt命令打印该结构地址

0:001> dt ntdll!_DPH_HEAP_ROOT CreateStackTrace 2f01000
   +0x0b8 CreateStackTrace : 0x0017cbe4 _RTL_TRACE_BLOCK

可以看到StackTrace的地址是 0x0017cbe4， 通过dds命令打印该地址内的符号

0:001> dds 0x0017cbe4 
0017cbe4  00178714
0017cbe8  00007001
0017cbec  000f0000
0017cbf0  5a8c8969 verifier!AVrfDebugPageHeapCreate+0x439
0017cbf4  7743a9e8 ntdll!RtlCreateHeap+0x41
0017cbf8  5a930109 vfbasics!AVrfpRtlCreateHeap+0x56
0017cbfc  755fdda2 KERNELBASE!HeapCreate+0x55
0017cc00  72893a4a MSVCR90!_heap_init+0x1b
0017cc04  72852bb4 MSVCR90!__p__tzname+0x2a
0017cc08  72852d5e MSVCR90!_CRTDLL_INIT+0x1e
0017cc0c  5a8dc66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0017cc10  5b069164 vrfcore!VfCoreStandardDllEntryPointRoutine+0x121
0017cc14  5a92689c vfbasics!AVrfpStandardDllEntryPointRoutine+0x9f
0017cc18  7741af58 ntdll!LdrpCallInitRoutine+0x14
0017cc1c  7741fd6f ntdll!LdrpRunInitializeRoutines+0x26f
0017cc20  774290c6 ntdll!LdrpInitializeProcess+0x137e
0017cc24  77428fc8 ntdll!_LdrpInitialize+0x78
0017cc28  7741b2f9 ntdll!LdrInitializeThunk+0x10
0017cc2c  00000000
0017cc30  00009001

现在我们可以看到该堆被Create时的完整堆栈了， 通过堆栈，我们可以看到该堆正是由crt创建的， 也就是说我们new的内存都分配在该堆内。

如果你觉得上面跟踪堆创建的过程太复杂，可以先忽略， 下面我们分析堆状态， 输入!heap -stat -h 0，它会分析所有堆的当前使用状态， 我们着重关注我们的crt堆02f00000：

Allocations statistics for
 heap @ 02f00000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    9c40 1 - 9c40  (52.66)
    14 3ea - 4e48  (26.38)
    1000 1 - 1000  (5.39)
    800 2 - 1000  (5.39)
    490 1 - 490  (1.54)
    248 1 - 248  (0.77)
    220 1 - 220  (0.72)
    214 1 - 214  (0.70)
    ac 2 - 158  (0.45)
    82 2 - 104  (0.34)
    6a 2 - d4  (0.28)
    50 2 - a0  (0.21)
    28 4 - a0  (0.21)
    98 1 - 98  (0.20)
    94 1 - 94  (0.19)
    8a 1 - 8a  (0.18)
    2e 3 - 8a  (0.18)
    41 2 - 82  (0.17)
    80 1 - 80  (0.17)
    7c 1 - 7c  (0.16)

我们可以看到排在第一位的是大小为0x9c40 (0n40000)的内存，分配了1次， 第二位的是大小为 0x14 (0n20) 的内存，分配了3ea (0n1002)次.
 回头再看我们的测试程序，怎么样？ 是不是感觉很熟悉了。

输入!heap -flt s 0x9c40， 让WinDbg列出所有大小为0x9c40的内存：

0:001> !heap -flt s 0x9c40
    _DPH_HEAP_ROOT @ 1161000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 1300000
    _DPH_HEAP_ROOT @ 1401000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 16b0000
    _DPH_HEAP_ROOT @ 2361000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 1280000
    _DPH_HEAP_ROOT @ 2f01000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
        02f024e0 : 02fc63c0 00009c40 - 02fc6000 0000b000
    _HEAP @ 31d0000

可以看到， WinDbg帮我们找到了一个符合要求的分配， 它的UserAddr是02fc63c0， 该地址实际上就是代码char* pLargeMem = new char[40000]分配的地址， 按照开头的方法， 输入!heap -p -a 02fc63c0

0:001> !heap -p -a 02fc63c0
    address 02fc63c0 found in
    _DPH_HEAP_ROOT @ 2f01000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 2f024e0:          2fc63c0             9c40 -          2fc6000             b000
    5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
    77447e5e ntdll!RtlpAllocateHeap+0x000000c4
    774134df ntdll!RtlAllocateHeap+0x0000023a
    5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
    5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
    72893db8 MSVCR90!malloc+0x00000079
    72893eb8 MSVCR90!operator new+0x0000001f
    012c101e MemLeakTest!wmain+0x0000001e [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 13]
    77331114 kernel32!BaseThreadInitThunk+0x0000000e
    7741b429 ntdll!__RtlUserThreadStart+0x00000070
    7741b3fc ntdll!_RtlUserThreadStart+0x0000001b

可以看到该堆栈就是我们new char[40000]的堆栈， 用同样的方法， 我们可以分析出上面代码for循环中的1000次内存泄漏。

最
后， 总结一下， 通过WinDbg结合AppVerifier， 我们可以详细的跟踪堆中new出来的每一块内存。
很多时候在没有源代码的Release版本中，在程序运行一段时间后，如果我们发现有大块内存或是大量同样大小的小内存一直没有释放，
 我们就可以用上面的方法进行分析。有些情况下，我们甚至可以将 _CrtDumpMemoryLeaks()和WinDbg的!heap -p -a [address]命令结合起来使用， 由前者打印泄漏地址，后者分析调用堆栈，以便快速的定位问题。

原文  http://www.cppblog.com/weiym/archive/2013/02/27/198109.html

时间： 2024-12-15 01:56:19

基于WinDbg的内存泄漏分析的相关文章

Node.js内存泄漏分析

在极客教育出版了一个视频是关于<Node.js 内存泄漏分析>,本文章主要是从内容上介绍如何来处理Node.js内存异常问题.如果希望学习可前往极客学院: 本文章的关键词 - 内存泄漏 - 内存泄漏检测 - GC分析 - memwatch 文章概要 由于内存泄漏在Node.js中非常的常见,可能在浏览器中应用javascript时,对于其内存泄漏不是特别敏感,但作为服务器语言运行时,你就不得不去考虑这些问题.由于很小的逻辑可能导致服务器运行一天或者一个星期甚至一个月才会让你发现内存不断上涨,而

内存泄漏分析工具tMemMonitor (TMM)使用简介

C/C++由于灵活.高效的优点一直以来都是主流的程序设计语言之一,但是其内存的分配与释放均由程序员自己管理,当由于疏忽或错误造成程序未能释放不再使用的内存时就会造成内存泄漏.在大型.复杂的应用程序中,内存泄漏往往是最常见的问题,因而及时解决内存泄漏非常必要.tMemMonitor (TMM)作为一个专业.准确.易用的内存泄漏分析工具,可以帮助C/C++程序员迅速地解决内存泄漏这个令人头疼的问题. TMM下载地址:http://download.csdn.net/download/tmemmoni

View的post方法导致的内存泄漏分析

简述: 写这篇文章的缘由是最近项目中查内存泄漏时,发现最终原因是由于异步线程调用View的的post方法导致的. 为何我会使用异步线程调用View的post方法,是因为项目中需要用到很多复杂的自定义布局,需要提前解析进入内存,防止在主线程解析导致卡顿,具体的实现方法是在Application启动的时候,使用异步线程解析这些布局,等需要使用的时候直接从内存中拿来用. 造成内存泄漏的原因,需要先分析View的post方法执行流程,也就是文章前半部分的内容 文章内容: View#post方法作用以及实

android 内存泄漏分析技巧

java虚拟机运行一般都有一个内存界限,超过这个界限,就会报outofmemory.这个时候一般都是存在内存泄漏.解决内存泄漏问题,窃以为分为两个步骤:分析应用程序是否真的有内存泄漏,找到内存泄漏的地方.这两个步骤都不是一般意义上的调试,直接打log,断点调试都不是太给力.动脑筋想一想,内存问题应该在很多地方上都会出现,这么常见的问题应该是有工具的.android现在更可以说是一个生态系统,当然也有很多开发辅助工具.在前面的两个步骤中都有很强大的武器,熟练的掌握这些利器,分析问题就会事半功倍.

使用Eclipse Memory Analyzer进行内存泄漏分析三部曲

源地址:http://seanhe.iteye.com/blog/898277 一.准备工作 分析较大的dump文件(根据我自己的经验2G以上的dump文件就需要使用以下介绍的方法,不然mat会出现oom)需要调整虚拟机参数 找个64位的系统在MemoryAnalyzer.ini设置-Xmx2g 如果是32位的xp可以使用下面的方法进行尝试: 安装jrockit 6.0的JDK mat使用jrockit的jdk来启动 Java代码   -vm D:/Program Files/Java/jroc

Java内存泄漏分析与解决方案

Java内存泄漏是每个Java程序员都会遇到的问题,程序在本地运行一切正常,可是布署到远端就会出现内存无限制的增长,最后系统瘫痪,那么如何最快最好的检测程序的稳定性,防止系统崩盘,作者用自已的亲身经历与各位网友分享解决这些问题的办法. 作为Internet最流行的编程语言之一,Java现正非常流行.我们的网络应用程序就主要采用Java语言开发,大体上分为客户端.服务器和数据库三个层次.在进入测试过程中,我们发现有一个程序模块系统内存和CPU资源消耗急剧增加,持续增长到出现java.lang.Ou

100%正确的内存泄漏分析工具 &#160; &#160; &nbsp; --------tMemMonitor (TMM)

C/C++由于灵活.高效的优点一直以来都是主流的程序设计语言之一,但是其内存的分配与释放均由程序员自己管理,当由于疏忽或错误造成程序未能释放不再使用的内存时就会造成内存泄漏.在大型.复杂的应用程序中,内存泄漏往往是最常见的问题,因而及时解决内存泄漏非常必要.tMemMonitor (TMM)作为一个专业.准确.易用的内存泄漏分析工具,可以帮助C/C++程序员迅速地解决内存泄漏这个令人头疼的问题. TMM下载地址: 一．开发背景 目前市面上已有一些Windows平台下的内存泄漏动态检测工具,比如U

Android内存泄漏分析实战

内存泄漏简单介绍 java能够保证当没有引用指向对象的时候,对象会被垃圾回收器回收.与c语言自己申请的内存自己释放相比,java程序猿轻松了非常多.可是并不代表java程序猿不用操心内存泄漏.当java程序发生内存泄漏的时候往往具有隐蔽性.因此要借助一些专业的平台资源去保证安全性,比如能够通过加密实现. 定义 引用百度百科的定义:"用动态存储分配函数动态开辟的空间,在使用完成后未释放,结果导致一直占领该内存单元. 直到程序结束".从程序员的角度来看"内存泄漏",事实

Android内存泄漏分析及调试

尊重原创作者,转载请注明出处: http://blog.csdn.net/gemmem/article/details/13017999 此文承接我的另一篇文章:Android进程的内存管理分析 首先了解一下dalvik的Garbage Collection: 如上图所示,GC会选择一些它了解还存活的对象作为内存遍历的根节点(GC Roots),比方说thread stack中的变量,JNI中的全局变量,zygote中的对象(class loader加载)等,然后开始对heap进行遍历.到最后,