vmmap是sysinternals工具集中的一个工具,主要用于分析一个进程的虚拟内存和物理内存的使用情况。更有效的是,可以通过对比两个不同时间的内存使用情况的Snapshot,来查找内存泄漏问题。
在这里,给大家重点推荐一下我的几个热门畅销专栏:
专栏1:(该专栏订阅量接近350个,有很强的实战参考价值,广受好评!)
C++软件异常排查从入门到精通系列教程(专栏文章列表,欢迎订阅,持续更新...)https://blog.csdn.net/chenlycly/article/details/125529931
本专栏根据近几年C++软件异常排查的项目实践,系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法,详细讲述了C++软件的调试方法与手段,以图文并茂的方式给出具体的实战问题分析实例,带领大家逐步掌握C++软件调试与异常排查的相关技术,适合基础进阶和想做技术提升的相关C++开发人员!
专栏中的文章都是通过项目实战总结出来的,有很强的实战参考价值!专栏文章还在持续更新中,预计文章篇数能更新到200篇以上!
专栏2:
C/C++基础与进阶(专栏文章,持续更新中...)https://blog.csdn.net/chenlycly/category_11931267.html
以多年的开发实战为基础,总结并讲解一些的C/C++基础与进阶内容,以图文并茂的方式对相关知识点进行详细地展开与阐述!专栏涉及了C/C++领域的多个方面的内容,同时给出C/C++及网络方面的常见笔试面试题,并详细讲述Visual Studio常用调试手段与技巧!
vmmap介绍
当你用vmmap去查看一个正在运行的进程的时候。可以看到如下图,不同类型的内存使用采用不同的颜色标明。VMMap主要列举了以下几种类型的内存使用情况:
- Free: 图中显示137434599232K,是不是被吓到了。这个一般是指虚拟地址空间。每个进程都有自己的虚拟地址空间,比如32位的一般为4G,其中2G是内核地址空间, 2GB用户态地址空间;64位理论上为2^64个字节,实际上没那么大,按照MSDN的描述64位的Windows用户态可使用地址空间为128TB。
- Heap: 这个主要就是指我们通过C/C++的malloc, new;以及HeapAlloc等申请的内存大小
- Image: 比较好理解,一般指进程启动的运行文件,比如Exe或者加载的DLL文件。
- Managed Heap: 这个一般指用C#编写代码使用的托管堆。比如一个程序可能是C#和C++均有实现,这个时候可以查看是不是托管堆占用的内存持续增高,那么就可以判断一般是C#部分托管堆使用有问题造成了泄漏。
- Mapped File: 主要是指内存映射文件,熟悉的同学应该知道,这也是常用的进程间通信的一种方式。
- Private Data: 主要指通过VirtualAlloc申请的内存空间。这里也注意同Free主要是指已经使用的地址空间,而非已经Commit的内存。比如下图中,
- Stack: 函数栈所使用的内存大小
- Shareable: 主要是进程间可以共享的内存,但是后备存储器为RAM或者Paging File(一般是指虚拟内存page.sys)。
- Page Table: 主要指内核中和该进程页表相关联的内存
对于其他的描述,本人本人主要介绍两种:
- Committed: 对于一个虚拟地址空间的使用,我们可以是申请地址空间,但不提交(commit),如果不提交,则不会占用真实的存储器空间(比如RAM或者Paging File),只有commit后才会使用物理内存(RAM或者Paging File)。那么VMMap这里所指的内存就是后备存储器为RAM, Paging File, 或者Mapped file。
- Working Set: 一般内存有RAM,还有虚拟内存(page.sys),而根据内存的调度原理,并不是所有的内存都常驻RAM。Working Set就是主要指在RAM中所使用的内存。
VMMap分析内存泄漏
笔者曾经有一次用过VMMap分析过内存泄漏,但是最终问题并不是通过VMMap分析出来的,主要是因为当运行到比较长的时间的时候VMMap偶尔会出现崩溃的情况。但是VMMap确实可以辅助分析出内存泄漏问题,笔者也是将这个方法分享给大家。
下面是一段便于读者理解Vmmap分析方法的样例。首先每隔10秒钟,申请10M内存,总共申请10次;然后每隔10秒释放1次内存,只释放5次。这样操作,可以简单模拟,一个程序在运行中既有正常的内存申请释放的场景,也有申请后却没有释放的场景,这样交错在一起,让问题更加逼近现实。这样也便于使用这种方法,在未来碰到问题的时候进行实战。
#include <iostream>
#include <chrono>
#include <thread>
#include <windows.h>
void HeapMemoryLeakSample()
{
const int iListSize = 10;
char* pHeapList[iListSize];
//Alloc 10 Heap STR_SIZE
const int STR_SIZE = 10 * 1000 * 1000;
for (int i = 0; i < iListSize; i++)
{
pHeapList[i] = new char [STR_SIZE];
strcpy_s(pHeapList[i], STR_SIZE, "Alloc Memory");
std::cout << pHeapList[i] << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(10));
}
//Free 5 Heap space
for (int i = 0; i < iListSize; i++)
{
if (i % 2 == 0)
{
delete pHeapList[i];
std::cout << "Free Memory" << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(10));
}
}
}
int main()
{
HeapMemoryLeakSample();
while (true)
{
std::this_thread::sleep_for(std::chrono::seconds(10));
}
return 0;
}
接下来一起来查看是如何定位一个程序的内存泄漏的。
第一步 配置好程序的位置,工作目录,以及符号文件目录:
第二步 当运行程序,首先看到整个VMMap界面。这个时候映入眼帘的好多好多数据,该看什么呢? 首先对于一般的C++程序而言,堆的内存泄漏使用是最常见,那么就先看下Heap部分的Committed大小是不是很大。比如本文的样例,发现已经有70M左右的大小。先锁定到溢出内存类型为Heap。
第三步 个人认为查找内存泄漏也需要一些技巧和常识的。比如程序刚启动不久的时候,申请的很多资源是全局的,或者伴随着整个进程的生命周期的,那么刚启动后的内存的增长一般可以忽略,不认为是内存泄漏的原因。再大概程序运行一段时间后(根据自己程序实际情况而定),基本的伴随整个进程的生命周期的资源已经创建完毕。此时可以使用Timeline和Address部分的功能对照查看。
这个时候首先选择Heap(点击一下),那么Address部分将会显示Heap所占用的内存。然后当我们打开Timeline,选择特定的时间段区域,比如上图中选择区域为刚开始申请内存的部分,每隔10秒,增加申请10M内存。此时重要的是Address部分也会动态的展示这段时间的内存变化。
然后注意其中的内存使用比如000001B39E445000的内存被申请了,然后拉长时间线,发现很长时间还是存在在Address栏中,并且绿色,就说明一直没有被释放。
此时当你选中这个地址,再选择Heap Allocations,便可以看到其申请的大小为10000000, 双击打开后便可以查看到函数调用栈了。如下图所示便可以找到是在HeapMemoryLeakSample函数内调用了new,并且有行号提示(不过这里的行号提示不够精准,但是也不影响你去分析问题了)。
也可以不选择区间,而选个某个时间点,查看内存的状态。
第四步 如果很幸运,第三步已经找到问题了。 第四步本来想说一说Call Stack的追踪的,比如通过申请的内存的Count或者Bytes来查找到可疑的内存泄漏点的函数调用栈。可是笔者多次实验后均发现,数据对不上。比如下图的Count百分比和Bytes百分比之和均对不上100%。所以笔者也不会对此做过多的赘述,调试软件同样也是软件,也可能存在bug或者一些限制。但是通过如上的方法和思想,也许能够协助你找到内存泄漏点,至少可以起到辅助的作用。