PerfView專題 (第四篇)：如何尋找 C# 中程式集泄漏

2022 年 8 月 15 日
筆記
perfview

一：背景

前兩篇我們都聊到了非託管記憶體泄漏，一個是 HeapAlloc ，一個是 VirtualAlloc，除了這兩種泄漏之外還存在其他渠道的記憶體泄漏，比如程式集泄漏，這一篇我們就來聊一聊。

二：程式集也會泄漏？

在我分析的一百多dump中，程式集方面的泄漏主要有 XmlSerializer 和 Castle.Proxy 這兩個入口，這裡就來探討 XmlSerializer 所造成的泄漏。

1. 問題程式碼

為了方便講述，先上一段測試程式碼，百分百記憶體泄漏，如假包換。


    internal class Program
    {
        static void Main(string[] args)
        {
            var xml = @" <FabrikamCustomer>
                              <Id>0001</Id>
                              <FirstName>John</FirstName>
                              <LastName>Dow</LastName>
                          </FabrikamCustomer>";

            Enumerable.Range(0, 30000)
                 .Select(i => GetCustomer(i, "FabrikamCustomer", xml))
                 .ToList();

            Console.WriteLine("處理完成！");
            Console.ReadLine();
        }
        public static Customer GetCustomer(int i, string rootElementName, string xml)
        {
            var xmlSerializer = new XmlSerializer(typeof(Customer),
                            new XmlRootAttribute(rootElementName));

            using (var textReader = new StringReader(xml))
            {
                using (var xmlReader = XmlReader.Create(textReader))
                {
                    Console.WriteLine(i);

                    return (Customer)xmlSerializer.Deserialize(xmlReader);
                }
            }

        }
    }
    public class Customer
    {
        public string Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }

故意讓程式調用 XmlSerializer 三萬次，跑完後我們看一下記憶體佔用情況。

從圖中你會觀察到，記憶體會一直往上飆，直到 1.35G 為止，很明顯這麼簡單的程式碼會有這麼大的記憶體佔用，已經超出了我的預期，接下來用 windbg 探究下到底怎麼回事？

2. windbg 調試

既然記憶體泄漏了，我們需要用 windbg 研判下到底是哪方面的記憶體泄漏，託管層還好說，如果是非託管 那又是頭大的事。。。先用 !address -summary 觀察下。


0:000> !heap -s


************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key                   : 0x14f82251
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00670000 00000002 1020232 1012572 1020020    901   235    67    0      2   LFH
008c0000 00001002      60     16     60      4     2     1    0      0      
00b20000 00001002      60     16     60      4     2     1    0      0      
023d0000 00001002      60      4     60      0     1     1    0      0      
025a0000 00041002      60      4     60      2     1     1    0      0      
04d80000 00041002      60      4     60      2     1     1    0      0      
-----------------------------------------------------------------------------
0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x3aeb6320
generation 1 starts at 0x3ae91000
generation 2 starts at 0x025b1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
025b0000  025b1000  02e70ee8  0x8bfee8(9174760)
3ae90000  3ae91000  3aeda364  0x49364(299876)
Large object heap starts at 0x035b1000
 segment     begin  allocated      size
035b0000  035b1000  036c2128  0x111128(1118504)
Total Size:              Size: 0xa1a374 (10593140) bytes.
------------------------------
GC Heap Size:    Size: 0xa1a374 (10593140) bytes.

從輸出資訊看，託管堆才區區 10M，可以看到記憶體主要被 NT Heap 給吃掉了，因為沒有開啟 ust ，所以這塊也搞不清楚是誰分配的。

如果仔細想一想，用 NT堆 的用戶除了作業系統，還有 CLR，對，就是 CLR，所以看看與之相關的高頻堆，低頻堆，程式碼堆，或許有什麼新發現，使用命令 !eeheap -loader。


0:000> !eeheap -loader
Loader Heap:
....
Module 57cf46f4: Size: 0x0 (0) bytes.
Module 57cf4e8c: Size: 0x0 (0) bytes.
Module 57cf5624: Size: 0x0 (0) bytes.
Module 57cf5dbc: Size: 0x0 (0) bytes.
Total size:      Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size:   Size: 0xff56000 (267739136) bytes.
=======================================

發現有海量的程式集，而且佔用了 267M，肯定是有問題的，接下來抽幾個 module 看下裡面都有什麼內容。


0:000> !dumpmt -md 57cf61f8
EEClass:         57d08298
Module:          57cf5dbc
Name:            
mdToken:         02000002
File:            Unknown Module
BaseSize:        0x44
ComponentSize:   0x0
Slots in VTable: 8
Number of IFaces in IFaceMap: 0
--------------------------------------
MethodDesc Table
   Entry MethodDe    JIT Name
78c497b8 7884c838 PreJIT System.Object.ToString()
78c496a0 78988978 PreJIT System.Object.Equals(System.Object)
78c521f0 78988998 PreJIT System.Object.GetHashCode()
78c04f2c 789889a0 PreJIT System.Object.Finalize()
57d10c85 57cf61d4   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.InitCallbacks()
57d10c89 57cf61dc   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer..ctor()
57d10c7d 57cf61bc   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.Write3_FabrikamCustomer(System.Object)
57d10c81 57cf61c8   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.Write2_Customer(System.String, System.String, ConsoleApp12.Customer, Boolean, Boolean)

可以發現這裡面都是 XmlSerialization 相關類，這說明記憶體泄漏和它有關，但還找不出是哪個程式碼泄漏的，頭疼哈。。。

3. 到底是誰泄漏的？

為了快速解決，這時候就可以祭出 PerfView 2.0.6（最新版本會報錯） , 用它來監控程式集的載入事件，一旦程式中出現了載入事件，在內部進行攔截並記錄 調用棧，主要還是藉助了 ETW。

在 PerfView 面板中點擊 Provider Browser 按鈕選中 Loader 事件，如下圖：

然後加上記錄棧的key，即 @StacksEnabled=true，合併後就是：


Microsoft-Windows-DotNETRuntime:LoaderKeyword:Always:@StacksEnabled=true

執行完之後，就會看到 Events 項，在彈框中搜索 AssemblyLoad 事件，然後在 Time MSec 列點擊右鍵選擇 Open Any Stacks 打開此次載入的 執行緒調用棧，如下圖所示：

如果看到調用棧顯示的是 亂碼 的話，可以使用 Lookup Symbols 載入下符號，然後就可以看到清晰的調用棧，截圖如下：

終於在 調用棧 中發現，那個 DynamicAssembly 就是 GetCustomer 方法創建的哈。。。到此終於找到原因。

Tags: perfview