偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

記一次 .NET某上位視覺程序離奇崩潰分析

開發(fā) 項(xiàng)目管理
熟悉 coreclr 底層的朋友應(yīng)該知道,gc 在標(biāo)記的過程中會(huì)給 mt 的第0位設(shè)置為1,表示當(dāng)前對(duì)象在深度優(yōu)先中已經(jīng)標(biāo)記過,防止重復(fù)標(biāo)記,當(dāng)然這個(gè)也是有源碼作證的。

一、背景

1. 講故事

前段時(shí)間有位朋友找到我,說他們有一個(gè)崩潰的dump讓我?guī)兔聪略趺椿厥隆?/p>

話不多說,既然有 dump 來了,那就上 windbg 說話吧。

二:WinDbg 分析

1. 為什么會(huì)崩潰

說實(shí)話windbg非常強(qiáng)大,雙擊打開dump就能第一時(shí)間幫你顯示出簡略的異常信息,輸出如下:

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 -v
clr!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用來做對(duì)象標(biāo)記之用的,所以大概率又是托管堆損壞,真是無語了,接下來用 !verifyheap 檢查下托管堆。

0:083> !verifyheap
object 00000218e96963d8: bad member 00000218E9696450 at 00000218E9696420
Last good object: 00000218E96963C0.
Could not request method table data for object 00000218E9696450 (MethodTable: 00007FFA35451300).
Last good object: 00000218E96963D8.

一看這卦就很不吉利,真的是有對(duì)象的mt是不對(duì)的,至此我們把崩潰的直接原因給找到了。

2. 為什么對(duì)象損壞了

要找到這個(gè)答案就需要深挖 00000218e96963d8 對(duì)象,分別使用 !do 命令以及 dp 來觀察內(nèi)存地址。

0:083> !do 00000218e96963d8
Name:        System.Threading.Tasks.Task+DelayPromise
MethodTable: 00007ffb3542b3e8
EEClass:     00007ffb3567c7c0
Size:        120(0x78) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
...
00007ffb35451300  40035d5       48 ...m.Threading.Timer  0 instance 00000218e9696450 Timer

0:083> dp 00000218e9696450 L6
00000218`e9696450  00007ffa`35451301 00000000`00000000
00000218`e9696460  00000218`e96964c8 00000000`00000000
00000218`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 00007ffb35451300
EEClass:         00007ffb356942f0
Module:          00007ffb353b1000
Name:            System.Threading.Timer
mdToken:         0000000002000504
File:            C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
BaseSize:        0x20
ComponentSize:   0x0
Slots in VTable: 23
Number of IFaces in IFaceMap: 1

0:083> !dumpmt 00007ffa35451301
00007ffa35451301 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位,接下來就要洞察為什么會(huì)有兩個(gè)bit位的翻轉(zhuǎn)?

3. 真的存在兩個(gè)bit位翻轉(zhuǎn)嗎

接下來我們逐一來聊一下。

  • bit 0 為什么會(huì)翻轉(zhuǎn)

熟悉 coreclr 底層的朋友應(yīng)該知道,gc 在標(biāo)記的過程中會(huì)給 mt 的第0位設(shè)置為1,表示當(dāng)前對(duì)象在深度優(yōu)先中已經(jīng)標(biāo)記過,防止重復(fù)標(biāo)記,當(dāng)然這個(gè)也是有源碼作證的,簡化后的代碼如下:

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è)正常情況。

  • bit 32 為什么會(huì)翻轉(zhuǎn)

這個(gè)是我無法解釋的,也正是因?yàn)檫@個(gè) bit32 的翻轉(zhuǎn)導(dǎo)致 gc 認(rèn)為這個(gè) obj 是一個(gè)損壞的對(duì)象,到底是什么原因呢?民間眾說紛紜,在我的過往分析旅程中我已見過兩例,但我不敢確定自己又遇到了輻射類的奇葩情況,所以也第一時(shí)間找朋友確認(rèn)程序周邊是否存在輻射環(huán)境。

圖片圖片

朋友反饋過來附近有 伺服電機(jī) 類,說實(shí)話工控的東西我是真的不太懂,只能上網(wǎng)搜搜這玩意是否有輻射,截圖如下:

圖片圖片

到底是不是這玩意導(dǎo)致的,其實(shí)我心里也沒底,跟朋友的溝通后說是只出現(xiàn)過一次,這就更加玄乎了。

圖片圖片

不管怎么說,我只能給出如下兩個(gè)方案:

  • 上 ECC 糾錯(cuò)內(nèi)存
  • 遠(yuǎn)離輻射環(huán)境

三:總結(jié)

在大工控領(lǐng)域里,這是我見過第三例bit位翻轉(zhuǎn)導(dǎo)致的程序崩潰,太無語了,惡魔到底是不是旁邊的 伺服電機(jī) ?

責(zé)任編輯:武曉燕 來源: 一線碼農(nóng)聊技術(shù)
相關(guān)推薦

2024-09-14 10:28:56

.NET卡死程序

2024-12-27 13:31:18

.NETdump調(diào)試

2022-10-25 14:17:01

.NET代碼程序

2024-03-28 12:56:36

2023-06-26 00:12:46

2025-10-29 01:11:00

.NET系統(tǒng)windows

2024-05-31 12:56:06

.NET代碼方法

2024-07-09 11:51:20

Windows線程池源碼

2023-06-29 17:55:00

.NET日志WinDbg

2023-03-26 20:24:50

ERP網(wǎng)站系統(tǒng)

2024-03-26 00:44:53

.NETCIM系統(tǒng)

2024-06-04 10:54:34

.NET代碼程序

2024-06-13 17:09:55

2022-10-09 10:47:37

NET視覺軟件

2024-06-06 10:51:15

自動(dòng)化系統(tǒng)推測

2025-09-05 02:22:00

.NETCRM物流行業(yè)

2023-04-06 10:52:18

2024-08-27 13:08:50

2024-05-28 10:18:30

WPF程序數(shù)據(jù)

2023-05-15 11:15:50

.NET門診語句
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)