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

作者：一線碼農聊技術 2024-07-12 11:20:34

開發項目管理

熟悉 coreclr 底層的朋友應該知道，gc 在標記的過程中會給 mt 的第0位設置為1，表示當前對象在深度優先中已經標記過，防止重復標記，當然這個也是有源碼作證的。

一、背景

1. 講故事

前段時間有位朋友找到我，說他們有一個崩潰的dump讓我幫忙看下怎么回事。

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

二：WinDbg 分析

1. 為什么會崩潰

說實話windbg非常強大，雙擊打開dump就能第一時間幫你顯示出簡略的異常信息，輸出如下：

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=????????

從卦中又看到了經典的 mark_object_simple1 方法，這個方法是GC用來做對象標記之用的，所以大概率又是托管堆損壞，真是無語了，接下來用 !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.

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

2. 為什么對象損壞了

要找到這個答案就需要深挖 00000218e96963d8 對象，分別使用 !do 命令以及 dp 來觀察內存地址。

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

仔細觀察卦中對象 00000218e9696450 所顯示的mt，你會發現一個是 00007ffb35451300，一個是 00007ffa35451301，很顯然前者是對的，后者是錯的，可以分別用 !dumpmt 做個驗證。

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

細心的朋友會發現雖然兩個mt地址不一樣，但已經非常相近，看樣子又是一例經典的bit位翻轉，我去，用 .formats 轉成二進制觀察一下，截圖如下：

圖片

從卦中可以清晰的看到當前地址有兩個 bit 的翻轉，分別是第0位和第32位，接下來就要洞察為什么會有兩個bit位的翻轉？

3. 真的存在兩個bit位翻轉嗎

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

bit 0 為什么會翻轉

熟悉 coreclr 底層的朋友應該知道，gc 在標記的過程中會給 mt 的第0位設置為1，表示當前對象在深度優先中已經標記過，防止重復標記，當然這個也是有源碼作證的,簡化后的代碼如下：

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);
}

有了這段源碼，這個 bit 為什么為 1 就能輕松的解釋了，所以這個翻轉是一個正常情況。