記一次 .NET某新能源MES 非托管泄露
作者：一線碼農聊技術
這次事故主要是朋友用 CSharpCodeProvider 動態生成程序集導致的程序集泄露，猜測代碼是在哪里 copy 過來的，一定要搞清楚原理才能放心用，合理創建合理釋放。
一：背景
1. 講故事
前些天有位朋友找到我，說他們的程序有內存泄露，跟著我的錯題集也沒找出是什么原因，剛好手頭上有一個 7G+ 的 dump，讓我幫忙看下是怎么回事，既然找到我了那就給他看看吧，不過他的微信頭像有點像 二道販子，不管到我這里是不是 三道，該分析的還得要分析呀。??????
二：WinDbg 分析
1. 到底是哪里的泄露
這個非常簡單，對用戶態內存段做一個分組處理就明白了，可以用 windbg 的 !address -summary 觀察便知。
0:000> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 44571 7ffc`f0900000 ( 127.988 TB) 99.99%
<unknown> 77531 2`47cee000 ( 9.122 GB) 74.52% 0.01%
Heap 16406 0`a45cf000 ( 2.568 GB) 20.98% 0.00%
Image 2116 0`15ad7000 ( 346.840 MB) 2.77% 0.00%
Stack 2286 0`0d160000 ( 209.375 MB) 1.67% 0.00%
TEB 762 0`005f4000 ( 5.953 MB) 0.05% 0.00%
Other 39 0`00207000 ( 2.027 MB) 0.02% 0.00%
PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 44571 7ffc`f0900000 ( 127.988 TB) 99.99%
MEM_COMMIT 86575 1`e571e000 ( 7.585 GB) 61.96% 0.01%
MEM_RESERVE 12566 1`29fd2000 ( 4.656 GB) 38.04% 0.00%從卦中可以清晰的看到 MEM_COMMIT=7.5G 同時 Heap=2.5G，說明可能是托管內存泄露，接下來用 !eeheap -gc 觀察下托管堆內存。
0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000020F1BC03E80
generation 1 starts at 0x0000020F1AFE7BA0
generation 2 starts at 0x0000020D2E4B1000
ephemeral segment allocation context: none
Small object heap
segment begin allocated committed allocated size committed size
0000020D2E4B0000 0000020D2E4B1000 0000020D3E4B0000 0000020D3E4B0000 0xffff000(268431360) 0xffff000(268431360)
0000020D09830000 0000020D09831000 0000020D1982FFE0 0000020D19830000 0xfffefe0(268431328) 0xffff000(268431360)
0000020D9D9E0000 0000020D9D9E1000 0000020DAD9DFFB8 0000020DAD9E0000 0xfffefb8(268431288) 0xffff000(268431360)
0000020DD50C0000 0000020DD50C1000 0000020DE50BFFB0 0000020DE50C0000 0xfffefb0(268431280) 0xffff000(268431360)
0000020E10B90000 0000020E10B91000 0000020E20B8FF10 0000020E20B90000 0xfffef10(268431120) 0xffff000(268431360)
0000020E54C60000 0000020E54C61000 0000020E64C60000 0000020E64C60000 0xffff000(268431360) 0xffff000(268431360)
0000020E9C050000 0000020E9C051000 0000020EAC04FF70 0000020EAC050000 0xfffef70(268431216) 0xffff000(268431360)
0000020ED89B0000 0000020ED89B1000 0000020EE89AFF20 0000020EE89B0000 0xfffef20(268431136) 0xffff000(268431360)
0000020F11FF0000 0000020F11FF1000 0000020F1C20E0A8 0000020F1C21A000 0xa21d0a8(169988264) 0xa229000(170037248)
Frozen object heap
segment begin allocated committed allocated size committed size
Large object heap starts at 0x0000020D3E4B1000
segment begin allocated committed allocated size committed size
0000020D3E4B0000 0000020D3E4B1000 0000020D460B3F00 0000020D460D4000 0x7c02f00(130035456) 0x7c23000(130166784)
0000020D72620000 0000020D72621000 0000020D7A19C808 0000020D7A19D000 0x7b7b808(129480712) 0x7b7c000(129482752)
0000020D7CFD0000 0000020D7CFD1000 0000020D84B0CDF0 0000020D84B2D000 0x7b3bdf0(129220080) 0x7b5c000(129351680)
0000020E08B90000 0000020E08B91000 0000020E0FAC4350 0000020E0FAC5000 0x6f33350(116601680) 0x6f34000(116604928)
0000020F2A040000 0000020F2A041000 0000020F2DB4A738 0000020F2DB4B000 0x3b09738(61904696) 0x3b0a000(61906944)
Total Allocated Size: Size: 0xabf0bd10 (2884680976) bytes.
Total Committed Size: Size: 0xabf5a000 (2885001216) bytes.
------------------------------
GC Allocated Heap Size: Size: 0xabf0bd10 (2884680976) bytes.
GC Committed Heap Size: Size: 0xabf5a000 (2885001216) bytes.從卦中數據看當前托管堆也才 2.8G，這就比較懵逼了，看樣子還是比較難搞的 非托管內存泄露，內存大概被 heap + VirtualAlloc/FileMap 合力吃掉了，接下來該怎么分析呢？有點迷茫。。。
2. 還有其他突破口嗎
一般來說這種問題看dump效果已經很不好了，比較好的方式就是用 perfview 去監控 VirtualAlloc，HeapAlloc 分配，但現在可惜的是我們只有一個dump，怎么辦呢？Windbg 命令除了可以看 ntheap，還可以看 clr 的私有堆，即 loader堆，或許有什么新的發現，可以使用命令 !eeheap -loader 。
0:000> !dumpdomain
--------------------------------------
System Domain: 00007fffeb742af0
...
--------------------------------------
Domain 1: 0000020d2c794430
Assembly: 0000020d59298350 [mr4vbdbg, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader: 0000020D579778E0
SecurityDescriptor: 0000020D593DE320
Module
00007fff8f0a5af8 mr4vbdbg, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Assembly: 0000020d5751b040 [51buoqnx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader: 0000020D57974130
SecurityDescriptor: 0000020D593E0060
Module
00007fff8f059798 51buoqnx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Assembly: 0000020d5751c000 [r2bjpfrk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader: 0000020D579741E0
SecurityDescriptor: 0000020D593DF340
Module
00007fff8f05aff8 r2bjpfrk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Assembly: 0000020d5929acf0 [qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader: 0000020D57976B20
SecurityDescriptor: 0000020D593DD6F0
Module
00007fff8f0a11d8 qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Total size: Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size: Size: 0x50f6d000 (1358352384) bytes total, 0x2f43000 (49557504) bytes wasted.
=======================================我去，不看不知道，一看嚇一跳，刷了好久也沒刷完，，，看了下總大小是 1.35G，說明當前程序存在著程序集泄露，而且程序集的名字也是奇奇怪怪的比如上面的 r2bjpfrk , qgt1j2cs, 看樣子都是動態生成出來的。
這里要提醒一下的是，不要看這里面是 1.35G，它還會涉及到其他未被關聯到的內存，比如 VirtualAlloc/MapFile/GCHeap 等等
接下來抽幾個 module 看看里面都定義了什么，使用 !dumpmodule -mt 命令即可。
0:000> !dumpmodule -mt 00007fff8f0a11d8
Name: qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Attributes: PEFile
Types defined in this module
MT TypeDef Name
------------------------------------------------------------------------------
00007fff8f0a1938 0x02000002 ServiceBase.WebService.DynamicWebLoad.xxxImplService
Types referenced in this module
MT TypeRef Name
------------------------------------------------------------------------------
00007fffc3232730 0x02000001 System.Web.Services.Protocols.SoapHttpClientProtocol
00007fffe81789e0 0x02000002 System.IAsyncResult
00007fffe81759d8 0x02000003 System.AsyncCallback
00007fffe15f42f8 0x02000004 System.Xml.Serialization.XmlElementAttribute
00007fffe57810a8 0x02000007 System.CodeDom.Compiler.GeneratedCodeAttribute
00007fffe80ee5f8 0x02000008 System.Diagnostics.DebuggerStepThroughAttribute
00007fffe5780210 0x02000009 System.ComponentModel.DesignerCategoryAttribute
00007fffc3239d60 0x0200000a System.Web.Services.WebServiceBindingAttribute
00007fffc323a2f8 0x0200000b System.Web.Services.Protocols.WebClientProtocol
00007fffc32322d8 0x0200000c System.Web.Services.Protocols.SoapDocumentMethodAttribute
00007fffe80f5dd8 0x0200000d System.Object
00007fffe80f59c0 0x0200000e System.String經過一頓搜索，發現模塊中都是這些內容，仔細分析 TypeDef Name 和 TypeRef Name，大概就能猜測到，代碼中有 SoapHttpClient 去訪問這個 xxxImplService 類名的服務地址，有了這些信息就可以分析源碼了。
3. 尋找源碼
很快就定位到了代碼，原來是在請求 WebService 的過程中用 CSharpCodeProvider 動態生成了程序集，而且還塞了 4個 dll，截圖如下：
圖片
到這里就知道了來龍去脈，最后就是讓朋友合理的去卸載這里的 程序集 ，或者干脆繞過去。
三：總結
這次事故主要是朋友用 CSharpCodeProvider 動態生成程序集導致的程序集泄露，猜測代碼是在哪里 copy 過來的，一定要搞清楚原理才能放心用，合理創建合理釋放。
責任編輯：武曉燕
來源：
一線碼農聊技術
