完整酒店网站开发,科技建筑公司网站,最简单的静态网站,河北智慧团建网站一#xff1a;背景 1. 讲故事说实话#xff0c;这篇dump我本来是不准备上一篇文章来解读的#xff0c;但它有两点深深的感动了我。无数次的听说用 Unity 可做游戏开发#xff0c;但百闻不如一见。游戏中有很多金庸武侠小说才有的名字#xff0c;太赏心悦目了。000000df315… 一背景 1. 讲故事说实话这篇dump我本来是不准备上一篇文章来解读的但它有两点深深的感动了我。无数次的听说用 Unity 可做游戏开发但百闻不如一见。游戏中有很多金庸武侠小说才有的名字太赏心悦目了。
000000df315978a8 0 3 玉骨扇
000000df31597cd8 0 3 云龙枪
000000df31596d88 0 3 阴风爪
000000df315967a8 0 4 雪魂丝链
000000df31596ad0 0 4 乙木神剑
000000df31596040 0 3 星耀冠
000000df31595328 0 3 乌金锤
...所以说这么好的一个dump我得给它留下点什么。好了话说回来这个缘分起于上个月有位朋友说它的程序虚拟内存占用非常大咨询如何解决如下图先甭管是什么问题多抓几个dump总不会错的几经折腾后发了一个dump过来。二Windbg 分析 1. 到底是哪里的泄漏分析内存方面的问题还是那句话一分为二看一下到底是哪一块的内存泄漏托管还是非托管。先看一下进程总内存使用 !address -summary 命令。
0:087 !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 458 7ffe9e6a8000 ( 127.995 TB) 100.00%
Heap 48514 1005fd000 ( 4.006 GB) 72.51% 0.00%
unknown 2504 02c6ad000 ( 710.676 MB) 12.56% 0.00%
Stack 504 02a000000 ( 672.000 MB) 11.88% 0.00%
Image 410 00a971000 ( 169.441 MB) 3.00% 0.00%
Other 18 0001dc000 ( 1.859 MB) 0.03% 0.00%
TEB 168 000150000 ( 1.312 MB) 0.02% 0.00%
PEB 1 000001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 51581 15130f000 ( 5.269 GB) 95.36% 0.00%
MEM_IMAGE 416 00aa6b000 ( 170.418 MB) 3.01% 0.00%
MEM_MAPPED 122 005bce000 ( 91.805 MB) 1.62% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 458 7ffe9e6a8000 ( 127.995 TB) 100.00%
MEM_COMMIT 51465 11c741000 ( 4.445 GB) 80.45% 0.00%
MEM_RESERVE 654 045207000 ( 1.080 GB) 19.55% 0.00%从卦中得知 MEM_COMMIT4.4G, 接下来再看下托管堆的内存占用可以用命令 !eeheap -gc 命令。
0:087 !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x000000df3118dc48
generation 1 starts at 0x000000df3118b098
generation 2 starts at 0x000000df30fc1000
ephemeral segment allocation context: nonesegment begin allocated size
000000df30fc0000 000000df30fc1000 000000df3178cae0 0x7cbae0(8174304)
Large object heap starts at 0x000000df40fc1000segment begin allocated size
000000df40fc0000 000000df40fc1000 000000df410637b8 0xa27b8(665528)
Total Size: Size: 0x86e298 (8839832) bytes.
------------------------------
GC Heap Size: Size: 0x86e298 (8839832) bytes.从卦中得知 GC Heap Size 8839832 Byte 8M我去才这么点有点开玩笑哈???????????????? 很明显这是非托管内存泄漏既然方向已定那就排查下非托管区域吧2. 探究非托管泄漏按照经验寻找非托管泄漏首先看下 loader 堆很多程序往往是因为动态创建了太多程序集所致比如经典的 Castle, XmlSerializer 有兴趣的朋友可以网上找下这方面的资料这里使用 !eeheap -loader 命令查看。
0:087 !eeheap -loader--------------------------------------
Jit code heap:
LoaderCodeHeap: 0000000000000000(0:0) Size: 0x0 (0) bytes.
Total size: Size: 0x0 (0) bytes.
--------------------------------------
Module Thunk heaps:
Module 00007ffda5fa1000: Size: 0x0 (0) bytes.
Module 00007ffd485c4148: Size: 0x0 (0) bytes.
Module 00007ffda2631000: Size: 0x0 (0) bytes.
Module 00007ffda5331000: Size: 0x0 (0) bytes.
Module 00007ffdac621000: Size: 0x0 (0) bytes.
Module 00007ffdac4e1000: Size: 0x0 (0) bytes.
Module 00007ffda48b1000: Size: 0x0 (0) bytes.
Module 00007ffda1791000: Size: 0x0 (0) bytes.
Module 00007ffd487b1858: Size: 0x0 (0) bytes.
Total size: Size: 0x0 (0) bytes.
--------------------------------------
Module Lookup Table heaps:
Module 00007ffda5fa1000: Size: 0x0 (0) bytes.
Module 00007ffd485c4148: Size: 0x0 (0) bytes.
Module 00007ffda2631000: Size: 0x0 (0) bytes.
Module 00007ffda5331000: Size: 0x0 (0) bytes.
Module 00007ffdac621000: Size: 0x0 (0) bytes.
Module 00007ffdac4e1000: Size: 0x0 (0) bytes.
Module 00007ffda48b1000: Size: 0x0 (0) bytes.
Module 00007ffda1791000: Size: 0x0 (0) bytes.
Module 00007ffd487b1858: Size: 0x0 (0) bytes.
Total size: Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size: Size: 0x99000 (626688) bytes total, 0x2000 (8192) bytes wasted.
从输出看: Total LoaderHeap size 626K看样子这次踏空了那就进困难模式看看 Windows NT 堆这里使用 !heap -s 命令。
0:087 !heap -s************************************************************************************************************************NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0xb6c37b3e3a4a189e
Termination on corruption : ENABLEDHeap Flags Reserv Commit Virt Free List UCR Virt Lock Fast (k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
000000df2e680000 00000002 4145084 4130108 4144304 1537 775 260 1 4 LFH
000000df2e1f0000 00008000 64 4 64 2 1 1 0 0
000000df2e830000 00001002 1860 172 1080 15 5 2 0 0 LFH
000000df2ec80000 00001002 1860 236 1080 5 7 2 0 0 LFH
000000df309e0000 00001002 60 8 60 2 1 1 0 0
000000df30bb0000 00041002 60 8 60 5 1 1 0 0
000000df49bd0000 00001002 840 44 60 3 3 1 0 0 LFH
000000df49b20000 00041002 1860 96 1080 8 3 2 0 0 LFH
000000df30b40000 00001002 60 20 60 9 2 1 0 0
000000df30b30000 00001002 1860 152 1080 11 8 2 0 0 LFH
000000df4bbb0000 00001002 3904 1292 3124 49 6 3 0 0 LFH
000000df89920000 00001002 1860 372 1080 14 7 2 0 0 LFH
000000df89be0000 00001006 1860 280 1080 23 2 2 0 0 LFH
000000df56f40000 00001006 32372 26204 31592 1434 21 6 0 6b LFH
000000df56f10000 00001006 1860 176 1080 21 3 2 0 0 LFH
000000df89ac0000 00001006 3904 2160 3124 67 4 3 0 2e LFH
-------------------------------------------------------------------------------------从输出信息看原来程序的内存都被 heap000000df2e680000 给吸走了那就深挖它吧这里用 !heap -stat -h 000000df2e680000 命令看一下该heap的统计信息。
0:087 !ext.heap -stat -h 000000df2e680000heap 000000df2e680000
group-by: TOTSIZE max-display: 20size #blocks total ( %) (percent of total busy bytes)2000 4cfd2 - 99fa4000 (68.76)58 9d7492 - 36201230 (24.17)12c 267e8 - 2d1c3e0 (1.26)21d1 c46 - 19f0b26 (0.72)4020 634 - 18dc680 (0.69)a0 26d00 - 1842000 (0.68)a 1d3ebb - 124734e (0.51)10 f8d99 - f8d990 (0.43)6 16adae - 881214 (0.24)b b3508 - 7b4758 (0.22)7 115125 - 793803 (0.21)5 17b833 - 7698ff (0.21)c 86027 - 6481d4 (0.18)9 afef9 - 62f6c1 (0.17)d 6a80f - 5688c3 (0.15)f 4f5a9 - 4a64e7 (0.13)e 54814 - 49f118 (0.13)8 8b092 - 458490 (0.12)13 3139b - 3a7481 (0.10)15 25d06 - 31a17e (0.09)从输出信息看这块heap主要是被 size2000 和 size58 给填满了毕竟他们占比 68.76 24.17 92.93所以挖他们很有必要接下来用命令 !heap -flt s 2000 找出heap中所有的这些block的首地址。
0:087 !ext.heap -flt s 2000_HEAP df2e680000HEAP_ENTRY Size Prev Flags UserPtr UserSize - state000000df2e702dd0 0201 0000 [00] 000000df2e702de0 02000 - (busy)000000df2e72c7e0 0201 0201 [00] 000000df2e72c7f0 02000 - (busy)000000df517400c0 0201 0201 [00] 000000df517400d0 02000 - (busy)000000df517420d0 0201 0201 [00] 000000df517420e0 02000 - (busy)000000df517440e0 0201 0201 [00] 000000df517440f0 02000 - (busy)000000df517460f0 0201 0201 [00] 000000df51746100 02000 - (busy)000000df51748100 0201 0201 [00] 000000df51748110 02000 - (busy)000000df5174a110 0201 0201 [00] 000000df5174a120 02000 - (busy)000000df5174c120 0201 0201 [00] 000000df5174c130 02000 - (busy)000000df5174e130 0201 0201 [00] 000000df5174e140 02000 - (busy)000000df51750140 0201 0201 [00] 000000df51750150 02000 - (busy)...
上面的 HEAP_ENTRY 就是block的首地址由于这样的block大概有 4cfd231.5w 个没法一一列出接下来就是用 dc 去观察这些 block 的内存块内容来发现其中规律手工肯定太麻烦了还是得借助下脚本,这里还是取前1w条查看。
function show_all_blocksize() {var output exec(!ext.heap -flt s 58).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:\\file\\ pageIndex .txt heap_entry_address L?0x58;var output exec(path);log(pageIndex pageIndex);
}执行脚本生成到txt之后截图如下通过观察发现这个heap中有大量的用户信息然后就拿这些信息求证朋友了。和朋友简单沟通后我也只能帮到这里到此结案。三总结 本次事故的原因是由于 C# 调用 Lua 后Lua 未作合理的内存释放造成的非托管泄漏具体怎么在代码层进行释放这个要看朋友的造化了。最后上一个小彩蛋朋友太客气了。没见过这么大的红包我居然收了 ????????????反手就给公司研发小伙伴一人一杯下午茶在这里对朋友说一声感谢 ????????????END工作中的你是否已遇到 ... 1. CPU爆高2. 内存暴涨3. 资源泄漏4. 崩溃死锁5. 程序呆滞等紧急事件全公司都指望着你能解决... 危难时刻才能展现你的技术价值作为专注于.NET高级调试的技术博主欢迎微信搜索: 一线码农聊技术免费协助你分析Dump文件希望我能将你的踩坑经验分享给更多的人。
