使用 vmmap 分析内存泄漏问题

╰+攻爆jí腚メ 2024-03-17 16:00 57阅读 0赞

vmmap是sysinternals工具集中的一个工具，主要用于分析一个进程的虚拟内存和物理内存的使用情况。更有效的是，可以通过对比两个不同时间的内存使用情况的Snapshot，来查找内存泄漏问题。

--------------------

在这里，给大家**重点推荐一下我的几个热门畅销专栏****：**

**专栏1：**（该专栏订阅量接近350个，有很强的实战参考价值，广受好评！）

**[C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/3312a0c2f05445d1bd9abf8730d205db.png][C_..._icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_chenlycly_article_details_125529931]**

> 本专栏根据近几年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，**以图文并茂的方式给出具体的实战问题分析实例**，带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！
> 
> **专栏中的文章都是通过项目实战总结出来的，有很强的实战参考价值！**专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！

**专栏2：**

[C/C++基础与进阶（专栏文章，持续更新中...）![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://blog.csdn.net/chenlycly/category\_11931267.html][C_C_..._icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_chenlycly_category_11931267.html]

> 以多年的开发实战为基础，总结并讲解一些的C/C++基础与进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域的多个方面的内容，同时给出C/C++及网络方面的常见笔试面试题，并详细讲述Visual Studio常用调试手段与技巧！

--------------------

### vmmap介绍 ###

![aab741835a0a4d26901a49deee78caa5.png][]

当你用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**: 主要指内核中和该进程页表相关联的内存

![在这里插入图片描述][20210530194404820.png]

对于其他的描述，本人本人主要介绍两种：

*  **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;
    }

接下来一起来查看是如何定位一个程序的内存泄漏的。

第一步 配置好程序的位置，工作目录，以及符号文件目录:

![在这里插入图片描述][20210601201031101.png]

![在这里插入图片描述][20210601201152956.png]

第二步 当运行程序，首先看到整个VMMap界面。这个时候映入眼帘的好多好多数据，该看什么呢？ 首先对于一般的C++程序而言，堆的内存泄漏使用是最常见，那么就先看下Heap部分的Committed大小是不是很大。比如本文的样例，发现已经有70M左右的大小。先锁定到溢出内存类型为Heap。

![在这里插入图片描述][20210601202733177.png]

第三步 个人认为查找内存泄漏也需要一些技巧和常识的。比如程序刚启动不久的时候，申请的很多资源是全局的，或者伴随着整个进程的生命周期的，那么刚启动后的内存的增长一般可以忽略，不认为是内存泄漏的原因。再大概程序运行一段时间后（根据自己程序实际情况而定），基本的伴随整个进程的生命周期的资源已经创建完毕。此时可以使用Timeline和Address部分的功能对照查看。

这个时候首先选择Heap(点击一下)，那么Address部分将会显示Heap所占用的内存。然后当我们打开Timeline，选择特定的时间段区域，比如上图中选择区域为刚开始申请内存的部分，每隔10秒，增加申请10M内存。此时重要的是Address部分也会动态的展示这段时间的内存变化。

![在这里插入图片描述][20210601203802180.png]

然后注意其中的内存使用比如000001B39E445000的内存被申请了，然后拉长时间线，发现很长时间还是存在在Address栏中，并且绿色，就说明一直没有被释放。

![在这里插入图片描述][20210601205754471.png]

此时当你选中这个地址，再选择Heap Allocations，便可以看到其申请的大小为10000000, 双击打开后便可以查看到函数调用栈了。如下图所示便可以找到是在HeapMemoryLeakSample函数内调用了new，并且有行号提示(不过这里的行号提示不够精准，但是也不影响你去分析问题了)。

也可以不选择区间，而选个某个时间点，查看内存的状态。

![在这里插入图片描述][20210601210502599.png]

第四步 如果很幸运，第三步已经找到问题了。 第四步本来想说一说Call Stack的追踪的，比如通过申请的内存的Count或者Bytes来查找到可疑的内存泄漏点的函数调用栈。可是笔者多次实验后均发现，数据对不上。比如下图的Count百分比和Bytes百分比之和均对不上100%。所以笔者也不会对此做过多的赘述，调试软件同样也是软件，也可能存在bug或者一些限制。但是通过如上的方法和思想，也许能够协助你找到内存泄漏点，至少可以起到辅助的作用。

![在这里插入图片描述][20210601215113644.png]

[icon-default.png_t_N7T8]: https://csdnimg.cn/release/blog_editor_html/release2.3.6/ckeditor/plugins/CsdnLink/icons/icon-default.png?t=N7T8
[C_..._icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_chenlycly_article_details_125529931]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/3312a0c2f05445d1bd9abf8730d205db.png
[C_C_..._icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_chenlycly_category_11931267.html]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/4aad92a40a344ba98c1676f9cf29fe79.png
[aab741835a0a4d26901a49deee78caa5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/81035b503f1747dcb446200de4a7733d.png
[20210530194404820.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/8ec2efba28254a1d9f9da84e582121ca.png
[20210601201031101.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7a92a1b81a074267b58215f47ee756af.png
[20210601201152956.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1421b5a9cc7f4e66b3c73c071f2d58c2.png
[20210601202733177.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/607f6584f7114f50a9b56971dc7aff37.png
[20210601203802180.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/6afa78b97a86495b99429e49fdb5a830.png
[20210601205754471.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d635e2873f534e54988e2746d2381c7d.png
[20210601210502599.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/2733378fdb5b4735976ab525273f1fb4.png
[20210601215113644.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/f209ece3f2fe4407a0689d11d8134229.png