记一次 .NET 某智慧水厂API 非托管内存泄漏分析

一:背景

1. 讲故事

七月底的时候有位朋友在wx上找到我,说他的程序内存占用8G,托管才占用1.5G,询问剩下的内存哪里去了?截图如下:

从求助内容看,这位朋友真的太客气了,动不动就谈钱,真伤感情,如果有朋友一直关注我的分享,应该知道我一直都是免费分析dump,当然我的知识和经验也是有边界的,有些dump我也搞不定,不过我还是尽自己最大努力去寻找答案。

在这里我有必要说一下职场,在我的潜意识或者在我的团队中,这些很难搞的问题当然由技术领导去搞定,但我发现有好几起却不是这样的,技术经理搞不定转包下来,下面搞不定就让他另请高明。。。????????????  有大佬可以分析下吗。

好了,闲话不多说,当务之急上windbg说话。

二:windbg 分析

1. 真的是非托管泄漏吗?

我在很多分析内存泄漏方面的文章都提到过,先要用二分法确定下是哪一部分的内存泄漏(托管还是非托管)。


0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    387     7df2`11ac1000 ( 125.946 TB)           98.39%
<unknown>                              2229      20c`a21bb000 (   2.049 TB)  99.75%    1.60%
Heap                                   1081        1`33914000 (   4.806 GB)   0.23%    0.00%
Image                                  1674        0`0e4be000 ( 228.742 MB)   0.01%    0.00%
Stack                                   973        0`0a140000 ( 161.250 MB)   0.01%    0.00%
TEB                                     324        0`00288000 (   2.531 MB)   0.00%    0.00%
Other                                    11        0`001d9000 (   1.848 MB)   0.00%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED                              300      200`00f9e000 (   2.000 TB)  97.35%    1.56%
MEM_PRIVATE                            3869        d`dd7ed000 (  55.461 GB)   2.64%    0.04%
MEM_IMAGE                              2124        0`0fda4000 ( 253.641 MB)   0.01%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                387     7df2`11ac1000 ( 125.946 TB)           98.39%
MEM_RESERVE                            1763      20b`d9903000 (   2.046 TB)  99.60%    1.60%
MEM_COMMIT                             4530        2`14c2c000 (   8.324 GB)   0.40%    0.01%


0:000> !eeheap -gc
Number of GC Heaps: 40
------------------------------
Heap Size:               Size: 0x3322e60 (53620320) bytes.
------------------------------
GC Heap Size:            Size: 0x603046b0 (1613776560) bytes.

!address -summary!eeheap -gc 两条命令看,确实如朋友所说:MEM_COMMIT=8.3G, GC Heap=1.5G, 我去,果然是难搞的非托管内存泄漏,既然是地狱模式,那就硬着头皮继续看吧,要想继续排查的话,首先得看 windows nt 堆。

2. 查看 windows nt堆

其实不管是托管的C#还是非托管的C,C++,它们分配内存最终都需要调用 Windows 的 VirtualAlloc,HeapAlloc API 到 windows nt 上,接下来的研究方向是如何查找这些 .net 看不到的 nt堆, 可以使用 windbg 的 !heap -s 命令。


0:000> !heap -s


************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key                   : 0x0e4dcfd61ab09dd9
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
000001bacd190000 00000002 4841944 4810424 4840388  13556  2042   303    2    dd8   LFH
000001baccfb0000 00008000      64      4     64      2     1     1    0      0      
000001bacd4d0000 00001002    8772   6748   7216   1045   191     4    0     38   LFH
    External fragmentation  15 % (191 free blocks)
000001bacdf90000 00001002    2636    404   1080     33     3     2    0      0   LFH
000001bace620000 00001002    8772   4052   7216   3874    13     7    0     1f   LFH
    External fragmentation  95 % (13 free blocks)
000001bace610000 00001003      60      8     60      6     1     1    0    N/A   
000001bace540000 00001002    1616     24     60      4     2     1    0      1   LFH
000001baceb50000 00001002    4680   1228   3124    504    99     3    0      0   LFH
    External fragmentation  41 % (99 free blocks)
000001baceb20000 00041002      60      8     60      5     1     1    0      0      
000001baceb10000 00041002    1616     68     60      4     3     1    0      0   LFH
000001c7738a0000 00001002   49336  19316  47780   8249    43    22    0    13b   LFH
    External fragmentation  42 % (43 free blocks)
000001c7753c0000 00001002   13712   8460  12156    968    29     6    0     1c   LFH
    External fragmentation  11 % (29 free blocks)
000001c7763f0000 00001002    8772   3944   7216    423    25     4    0     3f   LFH
000001ba977c0000 00001002    1080    376   1080    365     3     2    0      0      
-------------------------------------------------------------------------------------

从上面的信息可以看出,当前有 14个 heap,其中最大的一个heap占了 4.8G,为啥这个heap这么大?接下来详细看下这个heap,可使用 !ext.heap -stat -h 000001bacd190000


0:000> !ext.heap -stat -h 000001bacd190000
 heap @ 000001bacd190000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    20034 8eee - 11df90858  (96.44)
    2ee0000 2 - 5dc0000  (1.98)
    851 1c2b - ea419b  (0.31)
    2ac00 28 - 6ae000  (0.14)
    27d8 268 - 5fdfc0  (0.13)
    24000 28 - 5a0000  (0.12)
    d51 564 - 47c8a4  (0.09)
    10d1 3e7 - 419f97  (0.09)
    fd1 415 - 409025  (0.09)
    29d1 12f - 317e5f  (0.07)
    138 18b0 - 1e1680  (0.04)
    12c 188b - 1cc2e4  (0.04)
    1000 17e - 17e000  (0.03)
    2000 8e - 11c000  (0.02)
    200 899 - 113200  (0.02)
    ad1 178 - fe2f8  (0.02)
    478 367 - f3448  (0.02)
    7c8 1b9 - d6788  (0.02)
    1c038 7 - c4188  (0.02)
    f520 c - b7d80  (0.02)

可能很多人看不懂上面的卦象,首先 busy表示那些最近分配还未释放的,从卦头看,size=20034 的 block 有 36590 个,总占用:11df90858 = 4797827160byte = 4.7G,接下来的疑问很显然了,这些 block 里面到底都是些什么???要想找到答案,把这 3w 多的 block 信息都显示出来,可以用命令:!ext.heap -flt s 20034


0:000> !ext.heap -flt s 20034
    _HEAP @ 1bacd190000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        000001c771f2ad30 2004 0000  [00]   000001c771f2ad40    20034 - (busy)
        000001c774a65160 2004 2004  [00]   000001c774a65170    20034 - (busy)
        000001c774a851a0 2004 2004  [00]   000001c774a851b0    20034 - (busy)
        000001c774aa51e0 2004 2004  [00]   000001c774aa51f0    20034 - (busy)
        000001c774ac5220 2004 2004  [00]   000001c774ac5230    20034 - (busy)
        000001c774ae5260 2004 2004  [00]   000001c774ae5270    20034 - (busy)
        000001c774b052a0 2004 2004  [00]   000001c774b052b0    20034 - (busy)
        000001c774b29320 2004 2004  [00]   000001c774b29330    20034 - (busy)
        000001c774b49360 2004 2004  [00]   000001c774b49370    20034 - (busy)
        000001c774b693a0 2004 2004  [00]   000001c774b693b0    20034 - (busy)
        000001c774b893e0 2004 2004  [00]   000001c774b893f0    20034 - (busy)
          unknown!noop
        000001c774ba9420 2004 2004  [00]   000001c774ba9430    20034 - (busy)
        ...
        ...

block块信息太多,这里我就贴一部分上去,上面列的 HEAP_ENTRY 就是 block 的首地址,然后我通过 dc 一顿找,发现不少下面的输出。


0:000> dc 000001c774a65160 L 50
000001c7`74a65160  dddddddd 00000000 cada2944 0c85cc02  ........D)......
000001c7`74a65170  74a21070 000001c7 74a851b0 000001c7  p..t.....Q.t....
000001c7`74a65180  00000000 00000000 00000000 00000001  ................
000001c7`74a65190  00020000 00000000 0000007a fdfdfdfd  ........z.......
000001c7`74a651a0  00c801aa 55028000 05040355 44b60706  .......UU......D
000001c7`74a651b0  693d6f55 69502c31 32693d6e 7361502c  Uo=i1,Pin=i2,Pas
000001c7`74a651c0  726f7773 33733d64 6f72472c 693d7075  sword=s3,Group=i
000001c7`74a651d0  74532c34 54747261 3d656d69 452c3569  4,StartTime=i5,E
000001c7`74a651e0  6954646e 693d656d 75532c36 41726570  ndTime=i6,SuperA
000001c7`74a651f0  6f687475 657a6972 0a37693d 72657375  uthorize=i7.user
000001c7`74a65200  68747561 7a69726f 2c323d65 3d6e6950  authorize=2,Pin=
000001c7`74a65210  412c3169 6f687475 657a6972 656d6954  i1,AuthorizeTime
000001c7`74a65220  656e6f7a 693d6449 75412c32 726f6874  zoneId=i2,Author
000001c7`74a65230  44657a69 49726f6f 33693d64 6c6f680a  izeDoorId=i3.hol
000001c7`74a65240  79616469 482c333d 64696c6f 693d7961  iday=3,Holiday=i
000001c7`74a65250  6f482c31 6164696c 70795479 32693d65  1,HolidayType=i2
000001c7`74a65260  6f6f4c2c 33693d70 6d69740a 6e6f7a65  ,Loop=i3.timezon
000001c7`74a65270  2c343d65 656d6954 656e6f7a 693d6449  e=4,TimezoneId=i
000001c7`74a65280  75532c31 6d69546e 693d3165 75532c32  1,SunTime1=i2,Su
000001c7`74a65290  6d69546e 693d3265 75532c33 6d69546e  nTime2=i3,SunTim

说实话用dc一个一个找,真的太累,这里我就写一个简单的脚本,把前1w个block都dc出来看看内容咋样?


"use strict";

var index = 1;

function initializeScript() { return [new host.apiVersionSupport(1, 7)]; }
function log(str) { host.diagnostics.debugLog(str + "\n"); }
function exec(str) { log("\n" + str); return host.namespace.Debugger.Utility.Control.ExecuteCommand(str); }

function invokeScript() {
    show_heap_s();
}

function show_heap_s() {

    //get top 1 
    var output = exec("!heap -s").Skip(10).First();

    var h_address = output.split(' ')[0];

    show_max_blocksize(h_address);
}

function show_max_blocksize(address) {

    var output = exec("!ext.heap -stat -h " + address).Skip(3).First();

    var block_size = output.trim().split(' ')[0];

    show_all_blocksize(block_size);
}

function show_all_blocksize(blocksize) {

    var output = exec("!ext.heap -flt s " + blocksize).Take(10000);
    for (var line of output) {

        var heap_entry_address = line.trim().split(' ')[0];

        if (heap_entry_address.indexOf("00") == -1) continue;

        show_heap_entry(heap_entry_address);
    }
}

function show_heap_entry(heap_entry_address) {

    var pageIndex = (index++);

    var path = ".writemem D:\\dumps\\winform-memory-leak\\file\\" + pageIndex + ".txt " + heap_entry_address + " L?0x500";

    var output = exec(path);

    log("pageIndex=" + pageIndex);
}

脚本执行后,输出结果如下:

问了下朋友这些字符串大概是干嘛的?为啥非托管中有这么多的string没有得到释放,朋友告诉我这个大概是门禁相关业务,是通过 plc 方式和 C# 进行交互,分析到这里我能提供的信息都已提供了,接下来就要和门禁业务方确认下如何进一步定位和改进了。

三:总结

貌似这是20篇dump案例分享中第一个聊到非托管泄露的问题,曾今我在B站上说只专注于分析.NET托管内存泄漏,看样子很难实现哈,确实 C# 和 lua,C++,COM,内嵌浏览器 的交互造成非托管内存泄漏的例子数不胜数哈 ????????????

END

工作中的你,是否已遇到 ... 

1. CPU爆高

2. 内存暴涨

3. 资源泄漏

4. 崩溃死锁

5. 程序呆滞

等紧急事件,全公司都指望着你能解决...  危难时刻才能展现你的技术价值,作为专注于.NET高级调试的技术博主,欢迎微信搜索: 一线码农聊技术,免费协助你分析Dump文件,希望我能将你的踩坑经验分享给更多的人。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值