国产 无码 综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

記一次 .NET某賬本軟件 非托管泄露分析

這篇具有很好參考價值的文章主要介紹了記一次 .NET某賬本軟件 非托管泄露分析。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方,請大家不吝賜教,您也可以點(diǎn)擊"舉報違法"按鈕提交疑問。

一:背景

1. 講故事

中秋國慶長假結(jié)束,哈哈,在老家拍了很多的短視頻,有興趣的可以上B站觀看:https://space.bilibili.com/409524162 ,今天繼續(xù)給大家分享各種奇奇怪怪的.NET生產(chǎn)事故,希望能幫助大家在未來的編程之路上少踩坑。

話不多說,這篇看一個.NET程序集泄露導(dǎo)致的CLR私有堆泄露的案例,這個泄露和 JsonConvert 有關(guān),哈哈,相信你肯定比較驚訝!

二:WinDbg 分析

1. 到底是哪里的泄露

首先觀察一下進(jìn)程的提交內(nèi)存的大小,即通過 !address -summary 觀察。


0:000> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    390     7dfa`63fa8000 ( 125.978 TB)           98.42%
<unknown>                             13628      205`32974000 (   2.020 TB)  99.92%    1.58%
Heap                                   8143        0`4042b000 (   1.004 GB)   0.05%    0.00%
Stack                                   186        0`1f8e0000 ( 504.875 MB)   0.02%    0.00%
Image                                  1958        0`09775000 ( 151.457 MB)   0.01%    0.00%
Other                                     9        0`001d7000 (   1.840 MB)   0.00%    0.00%
TEB                                      62        0`0007c000 ( 496.000 kB)   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                              312      200`00a06000 (   2.000 TB)  98.92%    1.56%
MEM_PRIVATE                           21717        5`91ecd000 (  22.280 GB)   1.08%    0.02%
MEM_IMAGE                              1958        0`09775000 ( 151.457 MB)   0.01%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                390     7dfa`63fa8000 ( 125.978 TB)           98.42%
MEM_RESERVE                            4509      205`0fc14000 (   2.020 TB)  99.89%    1.58%
MEM_COMMIT                            19478        0`8c434000 (   2.192 GB)   0.11%    0.00%

當(dāng)前的提交內(nèi)存占用了 2.19G,進(jìn)程堆占用 1G ,差不多占了一半,但不能說明就是非托管內(nèi)存泄露,接下來繼續(xù)觀察下托管堆。


0:000> !eeheap -gc
Number of GC Heaps: 8
------------------------------
Heap 7 (000001C4971013A0)
generation 0 starts at 0x000001C817D201A0
generation 1 starts at 0x000001C817C878D8
generation 2 starts at 0x000001C817261000
ephemeral segment allocation context: none
         segment             begin         allocated              size
000001C817260000  000001C817261000  000001C819013F98  0x1db2f98(31141784)
Large object heap starts at 0x000001C907261000
         segment             begin         allocated              size
000001C907260000  000001C907261000  000001C907261018  0x18(24)
Pinned object heap starts at 0x000001C987261000
000001C987260000  000001C987261000  000001C9872ABA50  0x4aa50(305744)
Heap Size:       Size: 0x1dfda00 (31447552) bytes.
------------------------------
GC Heap Size:    Size: 0xba26488 (195191944) bytes.

從卦中可以看到當(dāng)前的托管堆占用僅 195M,這就更好的驗(yàn)證當(dāng)前確實(shí)存在非托管內(nèi)存泄露,由于非托管內(nèi)存沒有開啟 ust,也沒有 perfview 的etw文件,所以沒有好的方式進(jìn)一步挖掘,到這里可能就止步不前了。

2. 到底是哪里的泄露

在 C# 所處的 Windows 進(jìn)程中,其實(shí)有很多的堆,比如:crt堆,ntheap堆,gc堆,clr私有堆,堆外(VirtualAlloc),調(diào)試沒有標(biāo)準(zhǔn)答案,不斷的假設(shè),試探,摸著石頭過河,言外之意就是這個堆沒問題,不代表其他堆也沒有問題,這樣想思路就比較順暢了,我們可以看看其他的堆,比如這里的 CLR私有堆,使用 !eeheap -loader 觀察。


0:000> !eeheap -loader
Loader Heap:
--------------------------------------
...
Module 00007ff846e034c0: Size: 0x0 (0) bytes.
Module 00007ff846e03930: Size: 0x0 (0) bytes.
Module 00007ff846e04180: Size: 0x0 (0) bytes.
Module 00007ff846e047e0: Size: 0x0 (0) bytes.
Module 00007ff846e04e40: Size: 0x0 (0) bytes.
Total size:      Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size:   Size: 0x47252000 (1193615360) bytes total, 0x1f68000 (32931840) bytes wasted.
=======================================

從卦中可以看到有非常多的 module 迸射出來,估計有幾萬個,并且可以看到總的大小是 1.19G,到這里基本就搞清楚了,然來是 程序集泄露。

這里稍微補(bǔ)充一下,像這種問題早期可以使用 dotnet-counter 或者 Windows 的程序集指標(biāo) 監(jiān)控一下,或許你就能輕松找出原因,截圖如下:


PS C:\Users\Administrator\Desktop> dotnet-counters monitor -n WebApplication2

記一次 .NET某賬本軟件 非托管泄露分析

而且 dotnet-counter 還是跨平臺的,非常實(shí)用,大家可以琢磨琢磨,接下來抽一個module 用命令 !dumpmodule -mt 00007ff846e034c0 觀察下,內(nèi)部到底有哪些類型。


0:000> !dumpmodule -mt 00007ff846e034c0
Name: Unknown Module
Attributes:              Reflection IsDynamic IsInMemory 
Assembly:                000001c9e193b9e0
BaseAddress:             0000000000000000
...

Types defined in this module

              MT          TypeDef Name
------------------------------------------------------------------------------
00007ff846e03db0 0x02000002 

Types referenced in this module

              MT            TypeRef Name
------------------------------------------------------------------------------
00007ff820ff5748 0x02000002 xxx.xxx.Json.Converters.PolymorphismConverter`1
00007ff820e710f8 0x02000003 xxx.xxx.Models.IApiResult

0:000> !dumpmt -md 00007ff846e03db0
Number of IFaces in IFaceMap: 0
--------------------------------------
MethodDesc Table
           Entry       MethodDesc    JIT Name
00007FF822F05FA8 00007ff823285b50   NONE xxx.Json.Converters.PolymorphismConverter`1
00007FF822EFD5E8 00007ff82323b1b8   NONE System.Text.Json.Serialization.JsonConverter`1
00007FF822EFD5F0 00007ff82323b1c8   NONE System.Text.Json.Serialization.JsonConverter`1
00007FF8414CB978 00007ff846e03d88    JIT IApiResultDynamicJsonConverter..ctor()

仔細(xì)分析卦中信息,可以很明顯的看到。

  • Json.Converters.PolymorphismConverter

看樣子和牛頓有關(guān)系,并且還是一個自定義的 JsonConvert。

  • IApiResult 和 IApiResultDynamicJsonConverter

看樣子是一個接口的返回協(xié)議類,需要在代碼中重點(diǎn)關(guān)注。

有了這些信息,接下來就是重點(diǎn)關(guān)注代碼中的 PolymorphismConverter 類,果然就找到了一處。

記一次 .NET某賬本軟件 非托管泄露分析

從類的定義來看,一般這種東西都是在 ConfigureServices 方法中做 初始化定義 的,按理說問題不大,那為什么會有問題呢?還得要查下它的引用,終于給找到了,截圖如下:

記一次 .NET某賬本軟件 非托管泄露分析

這是一個低級錯誤哈,每次讀取 ApiResult.Data 的時候都要 jsonSerializerOptions.AddPolymorphism(); 操作,也就每次都會創(chuàng)建程序集,終于真相大白。

三:總結(jié)

這種程序集泄露導(dǎo)致的生產(chǎn)事故不應(yīng)該哈,反應(yīng)了團(tuán)隊(duì)中多人協(xié)作的時候還是有待提高!文章來源地址http://www.zghlxwxcb.cn/news/detail-711739.html

記一次 .NET某賬本軟件 非托管泄露分析

到了這里,關(guān)于記一次 .NET某賬本軟件 非托管泄露分析的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!

本文來自互聯(lián)網(wǎng)用戶投稿,該文觀點(diǎn)僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載,請注明出處: 如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符,請點(diǎn)擊違法舉報進(jìn)行投訴反饋,一經(jīng)查實(shí),立即刪除!

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

相關(guān)文章

  • 記一次 .NET 某醫(yī)院門診軟件 卡死分析

    記一次 .NET 某醫(yī)院門診軟件 卡死分析

    前幾天有位朋友找到我,說他們的軟件在客戶那邊卡死了,讓我?guī)兔聪率窃趺椿厥??我就讓朋友在程序卡死的時候通過 任務(wù)管理器 抓一個 dump 下來,雖然默認(rèn)抓的是 wow64 ,不過用 soswow64.dll 轉(zhuǎn)還是可以的,參考命令如下: 接下來就可以分析了哈。 首先用 !t 簡單看一下主

    2024年02月04日
    瀏覽(19)
  • 記一次 .NET某股票交易軟件 靈異崩潰分析

    記一次 .NET某股票交易軟件 靈異崩潰分析

    在dump分析的旅程中也會碰到一些讓我無法解釋的靈異現(xiàn)象,追過這個系列的朋友應(yīng)該知道,上一篇我聊過 宇宙射線 導(dǎo)致的程序崩潰,后來我又發(fā)現(xiàn)了一例,而這一例恰恰是高鐵的 列控連鎖一體化 程序,所以更加讓我確定這是由于 電離輻射 干擾了計算機(jī)的 數(shù)字信號 導(dǎo)致程

    2024年02月04日
    瀏覽(24)
  • 記一次 .NET 某拍攝監(jiān)控軟件 卡死分析

    記一次 .NET 某拍攝監(jiān)控軟件 卡死分析

    今天本來想寫一篇 非托管泄露 的生產(chǎn)事故分析,但想著昨天就上了一篇非托管文章,連著寫也沒什么意思,換個口味吧,剛好前些天有位朋友也找到我,說他們的拍攝監(jiān)控軟件卡死了,讓我?guī)兔Ψ治鱿聻槭裁磿ㄋ?,聽到這種軟件,讓我不禁想起了前些天 在程序員桌子上安

    2024年02月08日
    瀏覽(18)
  • 記一次 .NET 某企業(yè)內(nèi)部系統(tǒng) 崩潰分析

    記一次 .NET 某企業(yè)內(nèi)部系統(tǒng) 崩潰分析

    前些天有位朋友找到我,說他的程序跑著跑著就崩潰了,讓我看下怎么回事,其實(shí)沒怎么回事,抓它的 crash dump 就好,具體怎么抓也是被問到的一個高頻問題,這里再補(bǔ)一下鏈接: [.NET程序崩潰了怎么抓 Dump ? 我總結(jié)了三種方案] https://www.cnblogs.com/huangxincheng/p/14811953.html ,采用

    2024年02月10日
    瀏覽(22)
  • 記一次 .NET某防偽驗(yàn)證系統(tǒng) 崩潰分析

    記一次 .NET某防偽驗(yàn)證系統(tǒng) 崩潰分析

    昨晚給訓(xùn)練營里面的一位朋友分析了一個程序崩潰的故障,因?yàn)榭葱』镒幼蛱煸谌豪飭柫艘惶煲矝]搞定,干脆自己親自上陣吧,抓取的dump也是我極力推薦的用 procdump 注冊 AEDebug 的方式,省去了很多溝通成本。 windbg有一個非常強(qiáng)大的點(diǎn)就是當(dāng)你雙擊打開后,會自動幫你切換到

    2024年03月28日
    瀏覽(25)
  • 記一次 .NET 某企業(yè)采購平臺 崩潰分析

    記一次 .NET 某企業(yè)采購平臺 崩潰分析

    前段時間有個朋友找到我,說他們的程序有偶發(fā)崩潰的情況,讓我?guī)兔聪略趺椿厥?,針對這種 crash 的程序,用 AEDebug 的方式抓取一個便知,有了 dump 之后接下來就可以分析了。 既然是程序的崩潰,我們可以像看藍(lán)屏一下看dump文件,使用 !analyze -v 命令即可。 從上面的信息

    2024年02月11日
    瀏覽(24)
  • 記一次 .NET 某工控視覺系統(tǒng) 卡死分析

    記一次 .NET 某工控視覺系統(tǒng) 卡死分析

    前段時間有位朋友找到我,說他們的工業(yè)視覺軟件僵死了,讓我?guī)兔聪碌降资鞘裁辞闆r,哈哈,其實(shí)卡死的問題相對好定位,無非就是看主線程棧嘛,然后就是具體問題具體分析,當(dāng)然難度大小就看運(yùn)氣了。 前幾天看一篇文章說現(xiàn)在的 .NET程序員 不需要學(xué)習(xí) WinDbg ,理由就

    2024年02月12日
    瀏覽(21)
  • 記一次 .NET 某餐飲小程序 內(nèi)存暴漲分析

    記一次 .NET 某餐飲小程序 內(nèi)存暴漲分析

    前些天有位朋友找到我,說他的程序內(nèi)存異常高,用 vs診斷工具 加載時間又太久,讓我?guī)兔匆幌碌降渍厥拢貓D如下: 確實(shí),如果dump文件超過 10G 之后,市面上那些可視化工具分析起來會讓你崩潰的,除了時間久之外這些工具大多也不是用懶加載的方式,比如 dotmemory

    2024年02月08日
    瀏覽(15)
  • 記一次 .NET 某券商論壇系統(tǒng) 卡死分析

    記一次 .NET 某券商論壇系統(tǒng) 卡死分析

    前幾個月有位朋友找到我,說他們的的web程序沒有響應(yīng)了,而且監(jiān)控發(fā)現(xiàn)線程數(shù)特別高,內(nèi)存也特別大,讓我?guī)兔匆幌略趺椿厥?,現(xiàn)在回過頭來幾經(jīng)波折,回味價值太濃了。 這個程序內(nèi)存高,線程高,無響應(yīng),尼瑪是一個復(fù)合態(tài)問題,那怎么入手呢?按經(jīng)驗(yàn)推測,大概率是

    2024年02月05日
    瀏覽(32)
  • 記一次 .NET 某電力系統(tǒng) 內(nèi)存暴漲分析

    記一次 .NET 某電力系統(tǒng) 內(nèi)存暴漲分析

    前些天有位朋友找到我,說他生產(chǎn)上的程序有內(nèi)存暴漲情況,讓我?guī)兔聪略趺椿厥?,最簡單粗暴的方法就是讓朋友在?nèi)存暴漲的時候抓一個dump下來,看一看大概就知道咋回事了。 這個問題說的再多也不為過,一定要看清楚這個程序是如何個性化發(fā)展的,可以使用 !address

    2024年02月08日
    瀏覽(19)

覺得文章有用就打賞一下文章作者

支付寶掃一掃打賞

博客贊助

微信掃一掃打賞

請作者喝杯咖啡吧~博客贊助

支付寶掃一掃領(lǐng)取紅包,優(yōu)惠每天領(lǐng)

二維碼1

領(lǐng)取紅包

二維碼2

領(lǐng)紅包