一：背景
1. 講故事
上個(gè)月有個(gè)朋友在微信上找到我，說他們的軟件在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我?guī)兔聪略趺椿厥?，確實(shí)工控類的軟件環(huán)境復(fù)雜難搞，朋友手上有一個(gè)崩潰的dump，剛好丟給我來分析一下。
二：WinDbg分析
1. 程序?yàn)槭裁磿?huì)崩潰
windbg 有一個(gè)厲害之處在于雙擊之后可以幫你自動(dòng)定位到崩潰處，輸出如下：
................................................................
................................................................
.......................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1418.89c): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=????????
從卦中信息看，這不是一件好事情，崩潰居然落在bgc線程上，此時(shí)bgc線程正在做后臺(tái)對(duì)象標(biāo)記，依據(jù)過往經(jīng)驗(yàn)有可能是托管堆損壞了，可以用 !verifyheap 命令來驗(yàn)證下。
0:038> !verifyheap
Object 000000000476a0a8 has an invalid method table.
Last good object: 000000000476A058.
0:038> !lno 000000000476a0a8
Before: 000000000476a058 80 (0x50) System.Text.RegularExpressions.RegexWriter
After: 000000000476a0c0 152 (0x98) System.Int32[]
0:038> dp 000000000476a058
00000000`0476a058 000007fe`f0e47390 00000000`0476a0c0
00000000`0476a068 00000000`0476a1d0 00000000`0476a158
00000000`0476a078 00000000`0476a1a8 00000000`00000000
00000000`0476a088 0000001a`00000000 00000006`0000001a
00000000`0476a098 00000000`00000000 00000000`00000018
00000000`0476a0a8 00000000`00000000 00000000`00000000
00000000`0476a0b8 00000000`00000000 000007fe`f2ce9250
00000000`0476a0c8 00000000`00000020 00000004`00000000
從卦中看確實(shí)有一個(gè)對(duì)象處于有損狀態(tài)，它的 mt=0 ,objheader=0x18，這個(gè)信息還是蠻奇怪的，接下來觀察下內(nèi)存地址的布局，找出有損地址空間，截圖如下：
上面圈出來的地址段也不像是 C++ 故意改的，那到底是真破壞還是假破壞呢？因?yàn)檫@一點(diǎn)確實(shí)可以決定后續(xù)的分析方向。
2. 托管堆真假破壞之謎
熟悉 bgc 運(yùn)轉(zhuǎn)邏輯的朋友都知道會(huì)有三個(gè)階段，分別為 初始標(biāo)記,并發(fā)標(biāo)記,最終標(biāo)記，所以接下來的問題是當(dāng)前這個(gè)程序處于什么階段呢? 這個(gè)觀察手段比較多，除了看bgc流程也可以 !t -special 看看 SuspendEE 標(biāo)記。
0:038> !t -special
ThreadCount: 40
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
24 12 174c 000000001e71c210 1029220 Cooperative 0000000000000000:0000000000000000 000000000027ba40 2 MTA (GC) (Threadpool Worker)
...
38 13 89c 000000001e529130 21220 Preemptive 0000000000000000:0000000000000000 000000000027ba40 0 Ukn System.ExecutionEngineException 00000000022f1228
OSID Special thread type
24 174c SuspendEE ThreadpoolWorker
從卦中可以清晰的看到24號(hào)線程觸發(fā)了一個(gè)前臺(tái)GC，同時(shí)38號(hào)的 bgc拋了執(zhí)行引擎異常，這個(gè)災(zāi)難性的異常也是程序崩潰的原因，接下來觀察下 24號(hào)正在做什么。
0:024> k 10
# Child-SP RetAddr Call Site
00 00000000`205ebcf0 000007fe`f52fb444 clr!GcInfoDecoder::EnumerateLiveSlots+0x4df
01 00000000`205ec140 000007fe`f52fbd81 clr!EECodeManager::EnumGcRefs+0xc4
02 00000000`205ec2a0 000007fe`f5380aee clr!GcStackCrawlCallBack+0x171
03 00000000`205ec3a0 000007fe`f52fbc28 clr!Thread::StackWalkFrames+0x172
04 00000000`205ed820 000007fe`f53141f0 clr!CNameSpace::GcScanRoots+0x144
05 00000000`205ed8c0 000007fe`f5310a8e clr!WKS::gc_heap::relocate_phase+0x40
06 00000000`205ed930 000007fe`f5310fd0 clr!WKS::gc_heap::plan_phase+0xa01
07 00000000`205edb90 000007fe`f530df61 clr!WKS::gc_heap::gc1+0x9f
08 00000000`205edbe0 000007fe`f530dccd clr!WKS::gc_heap::garbage_collect+0x222
09 00000000`205edc70 000007fe`f530e220 clr!WKS::GCHeap::GarbageCollectGeneration+0xdd
0a 00000000`205edcc0 000007fe`f516ae69 clr!WKS::GCHeap::Alloc+0x29d
0b 00000000`205edd10 000007fe`f2b2ab2a clr!FramedAllocateString+0x139
...
從卦中可以清晰的看到此時(shí)的GC正在 relocate_phase 重定位階段，重定位階段通俗來說就是 兵馬未動(dòng)，糧草先行，這是一種非原子性的操作，簡(jiǎn)單來說bgc拿到的可能是移動(dòng)后的新地址（糧草），但對(duì)象（兵馬）還是在老地方，所以剛才看到的托管堆那塊空間是初始化狀態(tài)，同時(shí)對(duì)象頭的 0x18 應(yīng)該是一種中間狀態(tài)的對(duì)象標(biāo)記，這個(gè)暫時(shí)不去深挖了，但不管怎么說，此時(shí)的托管堆大概率是沒有問題的。
既然托管堆沒有問題，后面的研究方向就得深挖 bgc 的邏輯了。
3. bgc線程到底怎么了
要知道 bgc 到底怎么了，必須要觀察它附近的匯編代碼，可以用 ub 命令，輸出如下：
0:024> r
Last set context:
rax=000000000001b83b rbx=0000000020e5e5b0 rcx=0000000000370707
rdx=00000000029b78a0 rsi=0000000000000000 rdi=0000000020e5e0c0
rip=000007fef5316d40 rsp=0000000020e5e680 rbp=000000001a30a2fc
r8=0000000003707670 r9=000007fef2c94438 r10=00000000029b88b0
r11=0000000000000000 r12=0000000000000010 r13=000007fef2c94438
r14=0000000000291808 r15=0000000000001f60
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010244
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=????????
0:024> ub 000007fe`f5316d40
clr!WKS::gc_heap::background_mark_simple1+0x584:
000007fe`f5316d23 48c1e809 shr rax,9
000007fe`f5316d27 80e11f and cl,1Fh
000007fe`f5316d2a 41d3e3 shl r11d,cl
000007fe`f5316d2d 44855c8500 test dword ptr [rbp+rax*4],r11d
000007fe`f5316d32 7548 jne clr!WKS::gc_heap::background_mark_simple1+0x5f3 (000007fe`f5316d7c)
000007fe`f5316d34 44095c8500 or dword ptr [rbp+rax*4],r11d
000007fe`f5316d39 4d8b18 mov r11,qword ptr [r8]
000007fe`f5316d3c 4983e3fe and r11,0FFFFFFFFFFFFFFFEh
從卦中數(shù)據(jù)來看，崩潰的原因是 r11=0 導(dǎo)致的，r11 的值又來自于 r8，這里有一個(gè)硬編碼值 0FFFFFFFFFFFFFFFEh，這個(gè)值在代碼中應(yīng)該是 -2 或者是 ~1 這兩種情況，接下來觀察下 background_mark_simple1() 的方法源碼，尼瑪。。。 還真給我找到了，簡(jiǎn)化后如下：
void gc_heap::background_mark_simple1(uint8_t * oo THREAD_NUMBER_DCL)
{
...
uint8_t* start = oo;
if ((size_t)oo & 1)
{
oo = (uint8_t*)((size_t)oo & ~1);
start = *(--background_mark_stack_tos);
dprintf(4, ("oo: %Ix, start: %Ix\n", (size_t)oo, (size_t)start));
}
...
}
先簡(jiǎn)單解釋下代碼的意思， oo & ~1 是將 oo 對(duì)象的 gcmark標(biāo)記 給去掉，后面的 background_mark_stack_tos 就是深度優(yōu)先遍歷過程中使用的棧結(jié)構(gòu)，再結(jié)合匯編代碼，我們知道 r8 其實(shí)就是 oo，那這個(gè) oo 到底是獨(dú)立存在還是歸屬于誰呢？
4. oo 到底是何方神圣
要想知道這個(gè)答案，可以用 !lno 命令觀察下 r8 附近內(nèi)存來尋找蛛絲馬跡，輸出如下：
0:024> r r8
Last set context:
r8=0000000003707670
0:024> !lno 0000000003707670
Before: 0000000003707658 80 (0x50) xxx.ComponentData
After: 00000000037076a8 1416 (0x588) Free
Heap local consistency confirmed.
0:024> ? 0000000003707670 - 0000000003707658
Evaluate expression: 24 = 00000000`00000018
0:024> !DumpObj /d 0000000003707658
Name: xxx.ComponentData
MethodTable: 000007fe95c0b058
EEClass: 000007fe95c2bbb0
Size: 80(0x50) bytes
File: C:\xxxDriver.dll
Fields:
MT Field Offset Type VT Attr Value Name
000007fef2cecf58 400008c 38 System.DateTime 1 instance 0000000003707690 wWfscFiguq
000007fef2cffc90 400008d 18 System.Double 1 instance 0.000000 I9ss25rNyt
000007fe95c0a888 400008e 20 System.Int32 1 instance 9 AxCs5sGCxm
000007fe95c0af00 400008f 24 System.Int32 1 instance 9 fK9sgqZ2qY
...
這個(gè)卦看起來就非常奇怪，無語了。。。 我苦苦尋找的 oo 對(duì)象居然是一個(gè) int 類型的 fK9sgqZ2qY 字段，這不是亂套了嗎？ int 類型在這里也沒有裝箱，怎么可能會(huì)提取出 mt 呢？ 真的是莫名奇怪。
5. int 為什么當(dāng) 引用類型 了
線索到了這里越來越不可思議了，基本就可以斷定這是 BGC 標(biāo)記的錯(cuò)亂，直白的說就是 BGC 出現(xiàn)了 bug，再看下當(dāng)前的操作系統(tǒng)和framework的版本,依次是 windows7 和 4.0 。
0:024> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: kernel32.dll version: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
0:024> !eeversion
4.0.30319.18408 free
Workstation mode
In plan phase of garbage collection
SOS Version: 4.0.30319.18408 retail build
綜合來說是 bgc 在老環(huán)境下做后臺(tái)標(biāo)記的時(shí)候出現(xiàn)了 bug，這種 bug 非我能力之所及，但我能做的就是把它切除掉，即把 bgc 模式給關(guān)掉，不走這個(gè)邏輯不就行了嗎？ 參考如下：文章來源：http://www.zghlxwxcb.cn/news/detail-854480.html
<configuration>
<runtime>
<gcConcurrent enabled="false"/>
</runtime>
</configuration>
三：總結(jié)
很多時(shí)候分析下來發(fā)現(xiàn)是CLR內(nèi)部的bug所致，這種真的很無奈，我能做的也只能是手術(shù)切除。文章來源地址http://www.zghlxwxcb.cn/news/detail-854480.html
到了這里，關(guān)于記一次 .NET某爐膛鍋爐檢測(cè)系統(tǒng) 崩潰分析的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
