Golang 中的 io 包詳解：組合接口
io.ReadWriter// ReadWriter is the interface that groups the basic Read and Write methods.type ReadWriter interface { Reader Writer}是對(duì)Reader和Writer接口的組合，
前段時(shí)間有位朋友找到我，說(shuō)他們有一個(gè)崩潰的dump讓我?guī)兔聪略趺椿厥隆?span style="display:none">syO28資訊網(wǎng)——每日最新資訊28at.com
話不多說(shuō)，既然有 dump 來(lái)了，那就上 windbg 說(shuō)話吧。
說(shuō)實(shí)話windbg非常強(qiáng)大，雙擊打開dump就能第一時(shí)間幫你顯示出簡(jiǎn)略的異常信息，輸出如下：
This dump file has an exception of interest stored in it.The stored exception information can be accessed via .ecxr.(bf8.5dc4): Access violation - code c0000005 (first/second chance not available)For analysis of this file, run !analyze -vclr!WKS::gc_heap::mark_object_simple1+0x220:00007ffb`380453c4 833a00 cmp dword ptr [rdx],0 ds:00007ffa`35451300=????????從卦中又看到了經(jīng)典的 mark_object_simple1 方法，這個(gè)方法是GC用來(lái)做對(duì)象標(biāo)記之用的，所以大概率又是托管堆損壞，真是無(wú)語(yǔ)了，接下來(lái)用 !verifyheap 檢查下托管堆。
0:083> !verifyheapobject 00000218e96963d8: bad member 00000218E9696450 at 00000218E9696420Last good object: 00000218E96963C0.Could not request method table data for object 00000218E9696450 (MethodTable: 00007FFA35451300).Last good object: 00000218E96963D8.一看這卦就很不吉利，真的是有對(duì)象的mt是不對(duì)的，至此我們把崩潰的直接原因給找到了。
要找到這個(gè)答案就需要深挖 00000218e96963d8 對(duì)象，分別使用 !do 命令以及 dp 來(lái)觀察內(nèi)存地址。
0:083> !do 00000218e96963d8Name: System.Threading.Tasks.Task+DelayPromiseMethodTable: 00007ffb3542b3e8EEClass: 00007ffb3567c7c0Size: 120(0x78) bytesFile: C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dllFields:...00007ffb35451300 40035d5 48 ...m.Threading.Timer 0 instance 00000218e9696450 Timer0:083> dp 00000218e9696450 L600000218`e9696450 00007ffa`35451301 00000000`0000000000000218`e9696460 00000218`e96964c8 00000000`0000000000000218`e9696470 00007ffb`353e4b51 00000218`e9696368仔細(xì)觀察卦中對(duì)象 00000218e9696450 所顯示的mt，你會(huì)發(fā)現(xiàn)一個(gè)是 00007ffb35451300，一個(gè)是 00007ffa35451301，很顯然前者是對(duì)的，后者是錯(cuò)的，可以分別用 !dumpmt 做個(gè)驗(yàn)證。
0:083> !dumpmt 00007ffb35451300EEClass: 00007ffb356942f0Module: 00007ffb353b1000Name: System.Threading.TimermdToken: 0000000002000504File: C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dllBaseSize: 0x20ComponentSize: 0x0Slots in VTable: 23Number of IFaces in IFaceMap: 10:083> !dumpmt 00007ffa3545130100007ffa35451301 is not a MethodTable細(xì)心的朋友會(huì)發(fā)現(xiàn)雖然兩個(gè)mt地址不一樣，但已經(jīng)非常相近，看樣子又是一例經(jīng)典的bit位翻轉(zhuǎn)，我去，用 .formats 轉(zhuǎn)成二進(jìn)制觀察一下，截圖如下：
圖片
從卦中可以清晰的看到當(dāng)前地址有兩個(gè) bit 的翻轉(zhuǎn)，分別是第0位和第32位，接下來(lái)就要洞察為什么會(huì)有兩個(gè)bit位的翻轉(zhuǎn)？
接下來(lái)我們逐一來(lái)聊一下。
熟悉 coreclr 底層的朋友應(yīng)該知道，gc 在標(biāo)記的過(guò)程中會(huì)給 mt 的第0位設(shè)置為1，表示當(dāng)前對(duì)象在深度優(yōu)先中已經(jīng)標(biāo)記過(guò)，防止重復(fù)標(biāo)記，當(dāng)然這個(gè)也是有源碼作證的,簡(jiǎn)化后的代碼如下：
inline BOOL gc_heap::gc_mark(uint8_t* o, uint8_t* low, uint8_t* high, int condemned_gen){ if ((o >= low) && (o < high)) { BOOL already_marked = marked(o); if (already_marked) { return FALSE; } set_marked(o); return TRUE; }}#define marked(i) header(i)->IsMarked()BOOL IsMarked() const{ return !!(((size_t)RawGetMethodTable()) & GC_MARKED);}有了這段源碼，這個(gè) bit 為什么為 1 就能輕松的解釋了，所以這個(gè)翻轉(zhuǎn)是一個(gè)正常情況。
這個(gè)是我無(wú)法解釋的，也正是因?yàn)檫@個(gè) bit32 的翻轉(zhuǎn)導(dǎo)致 gc 認(rèn)為這個(gè) obj 是一個(gè)損壞的對(duì)象，到底是什么原因呢？民間眾說(shuō)紛紜，在我的過(guò)往分析旅程中我已見過(guò)兩例，但我不敢確定自己又遇到了輻射類的奇葩情況，所以也第一時(shí)間找朋友確認(rèn)程序周邊是否存在輻射環(huán)境。
圖片
朋友反饋過(guò)來(lái)附近有 伺服電機(jī) 類，說(shuō)實(shí)話工控的東西我是真的不太懂，只能上網(wǎng)搜搜這玩意是否有輻射，截圖如下：
圖片
到底是不是這玩意導(dǎo)致的，其實(shí)我心里也沒底，跟朋友的溝通后說(shuō)是只出現(xiàn)過(guò)一次，這就更加玄乎了。
圖片
不管怎么說(shuō)，我只能給出如下兩個(gè)方案：
在大工控領(lǐng)域里，這是我見過(guò)第三例bit位翻轉(zhuǎn)導(dǎo)致的程序崩潰，太無(wú)語(yǔ)了，惡魔到底是不是旁邊的 伺服電機(jī) ?
本文鏈接：http://www.www897cc.com/showinfo-26-100725-0.html記一次 .NET某上位視覺程序離奇崩潰分析
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)