基于WinDbg的内存泄漏分析
WinDbg的!heap命令非常强大,结合AppVerifier可以对堆(heap)内存进行详细的跟踪和分析, 我们接下来对下面的代码进行内存泄漏的分析:
//
#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,结果如下:
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
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 分析该堆的内存分配情况
_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命令打印该结构地址
+0x0b8 CreateStackTrace : 0x0017cbe4 _RTL_TRACE_BLOCK
可以看到StackTrace的地址是 0x0017cbe4, 通过dds命令打印该地址内的符号
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:
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)
我们可以看到排在第一位的是大小为0x 9c40 (0n40000)的内存,分配了1次, 第二位的是大小为 0x 14 (0n20) 的内存,分配了 3ea (0n1002)次.
回头再看我们的测试程序,怎么样? 是不是感觉很熟悉了。
输入 !heap -flt s 0x9c40, 让WinDbg列出所有大小为 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
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]命令结合起来使用, 由前者打印泄漏地址,后者分析调用堆栈,以便 快速的定位问题。
基于WinDbg的内存泄漏分析相关推荐
- 记一次 .NET 某外贸Web站 内存泄漏分析
一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了 ...
- 内存泄漏分析_调查内存泄漏第2部分–分析问题
内存泄漏分析 这个小型系列的第一个博客介绍了如何创建一个非常泄漏的示例应用程序,以便我们可以研究解决服务器应用程序上基于堆的问题的技术. 它展示了Producer-Consumer模式的一个大问题,即 ...
- 4大JVM性能分析工具详解,及内存泄漏分析方案
谈到性能优化分析一般会涉及到: Java代码层面的,典型的循环嵌套等 还会涉及到Java JVM:内存泄漏溢出等 MySQL数据库优化:分库分表.慢查询.长事务的优化等 阿里P8架构师谈:MySQL慢 ...
- php 在对象中递归 坑,PHP_PHP对象递归引用造成内存泄漏分析,通常来说,如果PHP对象存在递 - phpStudy...
PHP对象递归引用造成内存泄漏分析 通常来说,如果PHP对象存在递归引用,就会出现内存泄漏.这个Bug在PHP里已经存在很久很久了,先让我们来重现这个Bug,示例代码如下: class Foo { f ...
- Android MVP(三)内存泄漏分析与动态代理
博主声明: 转载请在开头附加本文链接及作者信息,并标记为转载.本文由博主 威威喵 原创,请多支持与指教. 本文首发于此 博主:威威喵 | 博客主页:https://blog.csdn.net/ ...
- 内存泄漏分析框架LeakCanary的使用与原理解析
文章目录 1. 常见内存泄漏 1.1 "单例模式" 造成的内存泄漏 1.2 "静态实例" 造成内存泄漏 1.3 "Handler" 造成的内 ...
- tMemMonitor (TMM) ----- 100%正确的内存泄漏分析工具
C/C++由于灵活.高效的优点一直以来都是主流的程序设计语言之一,但是其内存的分配与释放均由程序员自己管理,当由于疏忽或错误造成程序未能释放不再使用的内存时就会造成内存泄漏.在大型.复杂的应用程序中, ...
- 内存泄漏分析工具tMemMonitor (TMM)使用简介
内存泄漏分析工具tMemMonitor (TMM)使用简介 C/C++由于灵活.高效的优点一直以来都是主流的程序设计语言之一,但是其内存的分配与释放均由程序员自己管理,当由于疏忽或错误造成程序未能释放 ...
- android释放acitity内存,Android 内存泄漏分析与解决方法
在分析Android内存泄漏之前,先了解一下JAVA的一些知识 1. JAVA中的对象的创建 使用new指令生成对象时,堆内存将会为此开辟一份空间存放该对象 垃圾回收器回收非存活的对象,并释放对应的内 ...
最新文章
- [转贴]ASP优化之显示数据查询内容
- mysql8.0怎么导入数据_MySQL8.0导入数据
- VTK:在多面体数据上使用裁剪和封盖用法实战
- 計算機二級-java-03
- Bitmap对图像的处理
- ppt设置外观样式_ppt怎么设置幻灯片的背景一样?
- matlab入门---数值计算
- TwinCAT-C++基础
- FIFO设计中的注意问题与技巧
- timenote时光笔记+android,Time Note时光笔记软件怎么样?Time Note时光笔记有哪些功能特色?...
- Microsoft Teams安排 Teams 实时事件
- IC设计书籍信息收集
- ioremap、phys_to_virt和mmap
- 我在绑定微信账号时出现了问题,提示该微信已绑定其他账号
- 游戏设计的艺术:一本透镜的书——第十六章 故事和游戏结构能用间接控制巧妙地联合起来
- pion/ion搭建
- mysql一次count多个字段_SQL一次查出多个字段的COUNT值
- 谈谈市面上无线路由器的性能和芯片
- 趋势科技公司的创始人:张明正的创业路
- 菜鸟的数学建模之路(六):层次分析法
热门文章
- 数据库-优化-索引-索引的优化
- SpringBoot高级-消息-@RabbitListener@EnableRabbit
- Spring Environment
- oracle 11g goldengate与oracle 11g数据同步
- 解决针对ubuntu11.04安装中文包后不能正常查看或使用pdf和Archiver的问题
- 阿里云移动测试平台MQC移动测试沙龙第3期【北京站】
- 从“负电价”说起:谈谈德国新能源消纳的借鉴意义
- 支付宝支付集成,上传RSA公钥一直显示格式错误
- Fastreport.Net用户手册:报表页
- 第一章 简单工厂模式