PerfView专题 (第三篇)：如何寻找 C# 中的 VirtualAlloc 内存泄漏

一：背景

上一篇我们聊到了如何用 PerfView 去侦察 NTHeap 的内存泄漏，这种内存泄漏往往是用 C 的 malloc 或者 C++ 的 new 分配而不释放所造成的，这一篇我们来聊一下由 VirtualAlloc 方法造成的泄漏如何去甄别？

了解 VirtualAlloc 的朋友肯定说， C# 这种高层语言怎么可能会用 VirtualAlloc 呢？即便是 C++ 大概率也不会用这个，其实这么说还是世面见少了，经历的案例太少，接下来我们就来简要聊一聊。

二： C# 中真的会用 VirtualAlloc 吗

常规的 C# 内存分配确实不会直接调用 VirtualAlloc，但那些图形图形的工具方法肯定会直接用的，比如说 Bitmap，如果不信的话，我可以让你眼见为实，先上一段代码。



        static void Main(string[] args)

        {

            for (int i = 0; i < int.MaxValue; i++)

            {

                Test2();

                Console.WriteLine(i);

            }

            Console.ReadLine();

        }

        public static void Test2()

        {

            int width = 1000;

            int height = 1000;

            Bitmap bitmap = new Bitmap(width, height);

            string path = @"D:\test\1.jpg";

            bitmap.Save(path);

        }

这段代码中我会生成 1000x1000 的图片，接下来用 bp KernelBase!VirtualAlloc 去做一个拦截。



0:009> bp KernelBase!VirtualAlloc

0:009> g

Breakpoint 0 hit

KERNELBASE!VirtualAlloc:

00007ffd`0d53f9e0 4883ec38        sub     rsp,38h

0:000> k

 # Child-SP          RetAddr               Call Site

00 00000000`001ce828 00007ffc`eaaf4483     KERNELBASE!VirtualAlloc

01 00000000`001ce830 00007ffc`eaaf35fb     gdiplus!GpMemoryBitmap::AllocBitmapData+0x137

02 00000000`001ce870 00007ffc`eaacded1     gdiplus!GpMemoryBitmap::AllocBitmapMemory+0x3f

03 00000000`001ce8b0 00007ffc`eaacddf2     gdiplus!GpMemoryBitmap::InitNewBitmap+0x49

04 00000000`001ce8f0 00007ffc`eaacdf6f     gdiplus!CopyOnWriteBitmap::CopyOnWriteBitmap+0x8a

05 00000000`001ce930 00007ffc`eaace074     gdiplus!GpBitmap::GpBitmap+0x6b

06 00000000`001ce970 00007ffc`357d8143     gdiplus!GdipCreateBitmapFromScan0+0xc4

07 00000000`001ce9d0 00007ffc`357e8eb1     0x00007ffc`357d8143

08 00000000`001ceaa0 00007ffc`357d3288     System_Drawing_Common!System.Drawing.Bitmap..ctor+0x31 [_/src/libraries/System.Drawing.Common/src/System/Drawing/Bitmap.cs @ 80]

09 00000000`001ceaf0 00007ffc`357d2974     ConsoleApp7!ConsoleApp7.Program.Test2+0x58 [D:\net6\ConsoleApp1\ConsoleApp7\Program.cs @ 27]

...

从输出中可以看到在 Program.Test2调用的过程中果然被 VirtualAlloc 拦住了，而区区 200 多个 Bitmap 就已经分配了 1G 个内存，截图如下：

而此时的 GCHeap 上才区区 1.7M。



0:000> !eeheap -gc

Number of GC Heaps: 1

generation 0 starts at 0x0000000002941030

generation 1 starts at 0x0000000002941018

generation 2 starts at 0x0000000002941000

ephemeral segment allocation context: none

         segment             begin         allocated         committed    allocated size    committed size

0000000002940000  0000000002941000  0000000002ADFFE8  0000000002AE2000  0x19efe8(1699816)  0x1a1000(1708032)

Large object heap starts at 0x0000000012941000

         segment             begin         allocated         committed    allocated size    committed size

0000000012940000  0000000012941000  0000000012941018  0000000012942000  0x18(24)  0x1000(4096)

Pinned object heap starts at 0x000000001A941000

000000001A940000  000000001A941000  000000001A949C10  000000001A952000  0x8c10(35856)  0x11000(69632)

Total Allocated Size:              Size: 0x1a7c10 (1735696) bytes.

Total Committed Size:              Size: 0x1a2000 (1712128) bytes.

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

GC Allocated Heap Size:    Size: 0x1a7c10 (1735696) bytes.

GC Committed Heap Size:    Size: 0x1a2000 (1712128) bytes.

非常明显的非托管泄漏。

三：如何用 Perfview 检测

perfview 是一个非常好的运行时检测工具，它也是根据钩子函数拦截后看分配量来做一个权重，最终根据权重占比寻找到问题函数调用栈。

勾选上 VirtualAlloc 之后就可以点击 Start Collection，5s 之后就会生成一个 统计报表 ，我们点击 Memory -> Net Virtual Alloc Stacks 选项。

在弹出面板中选择我们的程序，点击 CallTree 面板，清除 GroupPats 分组，截图如下：

从面板中可以看到，在内存分配权重总量上，Test2() 占比 97.9%, 说明确实是一个问题，而且是初始化 Bitmap 出来的。

到这里， VirtualAlloc 的泄漏问题就找出来了，如果用 WinDbg 分析的话，还需要开启 ust 选项，也是记录线程栈，但使用起来相对繁琐。