當(dāng)前位置：首頁(yè) > 运维知识 > windows >内容正文

windows

记一次 .NET 某新能源材料检测系统崩溃分析

發(fā)布時(shí)間：2023/12/24 windows 37 coder

生活随笔收集整理的這篇文章主要介紹了记一次 .NET 某新能源材料检测系统崩溃分析小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

一：背景

1. 講故事

上周有位朋友找到我，說(shuō)他的程序經(jīng)常會(huì)偶發(fā)性崩潰，一直沒(méi)找到原因，自己也抓了dump 也沒(méi)分析出個(gè)所以然，讓我?guī)兔聪略趺椿厥拢羌热挥?dump，那就開(kāi)始分析唄。

二：Windbg 分析

1. 到底是哪里的崩潰

一直跟蹤我這個(gè)系列的朋友應(yīng)該知道分析崩潰第一個(gè)命令就是 !analyze -v ，讓windbg幫我們自動(dòng)化異常分析。


0:033> !analyze -v
CONTEXT:  (.ecxr)
rax=00000039cccff2d7 rbx=00000039c85fc2b0 rcx=00000039cccff2d8
rdx=0000000000000000 rsi=0000000000000000 rdi=00000039c85fbdc0
rip=00007ffb934b1199 rsp=00000039c85fc550 rbp=00000039c85fc5b8
 r8=0000000000000000  r9=00000039c85fce90 r10=0000000000000009
r11=0000000000000080 r12=0000000000000000 r13=00000039c85fdaf0
r14=00007ffb933d12b0 r15=0000022939e68440
iopl=0         nv up ei pl nz ac pe cy
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010211
clr!Frame::HasValidVTablePtr+0x2a:
00007ffb`934b1199 488b39          mov     rdi,qword ptr [rcx] ds:00000039`cccff2d8=????????????????
Resetting default scope

STACK_TEXT:  
00000039`c85fc550 00007ffb`934b7107     : 00007ffb`933140d0 00007ffb`933140d0 00000000`00000000 00000000`00000000 : clr!Frame::HasValidVTablePtr+0x2a
00000039`c85fc600 00007ffb`933d3427     : 00000000`00000000 00000000`00000000 00007ffb`93c641e0 00007ffb`93c64c48 : clr!GCToEEInterface::GcScanRoots+0x2f2
00000039`c85fdac0 00007ffb`933d1843     : 00000000`00000000 00007ffb`00000000 00000000`00000000 00000000`00000001 : clr!WKS::gc_heap::mark_phase+0x197
00000039`c85fdb70 00007ffb`933d1762     : 00000000`00000001 00000039`00000000 00000000`00000000 00000000`00000001 : clr!WKS::gc_heap::gc1+0xa3
00000039`c85fdbd0 00007ffb`933d1539     : 00000000`00000001 00000000`00000000 00000229`00af0f88 00000000`00000000 : clr!WKS::gc_heap::garbage_collect+0x54c
00000039`c85fdc50 00007ffb`933d5f51     : 00000000`00000578 00007ffb`00000000 00000229`01ee5200 00000039`c85fdca0 : clr!WKS::GCHeap::GarbageCollectGeneration+0x10d
00000039`c85fdcb0 00007ffb`933d838c     : 00000229`01ee5288 00000000`00000030 00000229`2328ff18 00000229`2328ff18 : clr!WKS::gc_heap::trigger_gc_for_alloc+0x2d
00000039`c85fdcf0 00007ffb`9333a88b     : 00000000`00000030 00000000`00000008 00000000`00000000 00007ffb`00000000 : clr!WKS::GCHeap::Alloc+0x2a9
00000039`c85fdd50 00007ffb`9333a465     : ffffffc6`37a021c8 00000039`c85fded0 00000039`c85fde20 00000039`c85fdf00 : clr!SlowAllocateString+0x8b
...

從卦中的調(diào)用棧來(lái)看，有如下兩點(diǎn)信息：

GC 觸發(fā)了

上面的mark_phase表示當(dāng)前 GC 正在標(biāo)記階段，后面的GcScanRoots表示 GC正在線程棧上尋找根對(duì)象。

崩潰點(diǎn)在 clr 中

看到崩潰在clr的 clr!Frame::HasValidVTablePtr 方法中真的有點(diǎn)不敢相信，從崩潰點(diǎn)的匯編代碼 rdi,qword ptr [rcx] 來(lái)看，貌似 rcx 沒(méi)有分配到物理內(nèi)存，可以用 !address rcx 驗(yàn)證下。


0:033> !address rcx

Usage:                  Free
Base Address:           00000039`ccb00000
End Address:            00000039`cce00000
Region Size:            00000000`00300000 (   3.000 MB)
State:                  00010000          MEM_FREE
Protect:                00000001          PAGE_NOACCESS
Type:                   <info not present at the target>


Content source: 0 (invalid), length: 1fbd28

尼瑪，真的好無(wú)語(yǔ)，這個(gè)rcx=00000039cccff2d8 所處的內(nèi)存居然是一個(gè) MEM_FREE，訪問(wèn)它自然會(huì)拋異常，現(xiàn)在很迷茫的是這玩意是 GC 的內(nèi)部邏輯，按理說(shuō)不會(huì)有這種異常，難道是 CLR 自己的 bug 嗎？

三：真的是 CLR 的 bug 嗎

1. 分析 CLR 源碼

要想尋找真相，就必須要理解崩潰處的 CLR 源碼了，這里拿coreclr做參考，首先從 clr!Frame::HasValidVTablePtr+2a 處說(shuō)起，這個(gè)方法大概就是用來(lái)判斷 Frame 類的虛方法表指針是否有效，簡(jiǎn)化后的代碼如下：


// static
bool Frame::HasValidVTablePtr(Frame * pFrame)
{
    TADDR vptr = pFrame->GetVTablePtr();
    if (vptr == HelperMethodFrame::GetMethodFrameVPtr())
        return true;

    if (vptr == DebuggerSecurityCodeMarkFrame::GetMethodFrameVPtr())
        return true;
    if (s_pFrameVTables->LookupValue(vptr, (LPVOID) vptr) == (LPVOID) INVALIDENTRY)
        return false;

    return true;
}

這里簡(jiǎn)單說(shuō)下什么是虛方法表，如果一個(gè)類通過(guò)各種渠道擁有了虛方法后，那這個(gè)類的第一個(gè)字段就是 虛方法表指針，這個(gè)指針?biāo)赶虻奶摲椒ū碇写娣胖總€(gè)虛方法的入口地址，畫(huà)個(gè)圖大概是這樣。

有了這張圖再讓chatgpt寫(xiě)一段C++代碼驗(yàn)證下。


#include <iostream>

using namespace std;

// 父類
class Animal {
private:
	int age;
public:
	virtual void makeSound() {
		cout << "The animal makes a sound" << endl;
	}
};

// 子類
class Cat : public Animal {
public:
	void makeSound() override {
		cout << "The cat meows" << endl;
	}
};

int main() {

	// 使用父類指針指向子類對(duì)象，調(diào)用子類重寫(xiě)的方法
	Animal* animal = new Cat();
	animal->makeSound(); // 輸出 "The cat meows"
	return 0;
}

上圖中的00219b60就是虛方法表指針，后面的0021100a就是虛方法地址了。

有了這些鋪墊之后，可以得知是在提取frame虛方法指針的時(shí)候，這個(gè)地址已被釋放導(dǎo)致崩潰的。

2. frame來(lái)自于哪里

通過(guò)在 coreclr 源碼中一頓梳理，發(fā)現(xiàn)它是 Thread 類的第四個(gè)字段，偏移是0x10，參考代碼如下：


PTR_GSCookie Frame::SafeGetGSCookiePtr(Frame* pFrame)
{
	Frame::HasValidVTablePtr(pFrame)
}

BOOL StackFrameIterator::Init(Thread* pThread,
	PTR_Frame   pFrame,
	PREGDISPLAY pRegDisp,
	ULONG32     flags)
{
	m_crawl.pFrame = m_pThread->GetFrame();
	m_crawl.SetCurGSCookie(Frame::SafeGetGSCookiePtr(m_crawl.pFrame));
}

0:008> dt coreclr!Thread
   +0x000 m_stackLocalAllocator : Ptr64 StackingAllocator
   +0x008 m_State          : Volatile<enum Thread::ThreadState>
   +0x00c m_fPreemptiveGCDisabled : Volatile<unsigned long>
   +0x010 m_pFrame         : Ptr64 Frame

觀察源碼大概就知道了 Frame 是棧幀的表示，標(biāo)記階段要在每個(gè)線程中通過(guò) m_pThread->GetFrame 方法來(lái)獲取爬棧的起始點(diǎn)。

到這里我們知道了 m_pFrame 有問(wèn)題，那它到底屬于哪個(gè)線程呢？

3. 尋找問(wèn)題 Thread

要想尋找問(wèn)題線程，可以自己寫(xiě)個(gè)腳本，判斷下 ThreadOBJ-0x10 = rcx(00000039cccff2d8) 即可。


function invokeScript() {

    var lines = exec("!t").Skip(8);

    for (var line of lines) {
        var t_addr = line.substr(15, 16);

        var commandText = "dp " + t_addr + " L8";
        log(commandText);

        var output = exec(commandText);

        for (var line2 of output) {
            log(line2);
        }

        log("--------------------------------------")
    }
}

從卦中數(shù)據(jù)看終于給找到了，原來(lái)是有一個(gè)OSID=744的線程意外退出導(dǎo)致棧空間被釋放引發(fā)的，真的無(wú)語(yǔ)了。

接下來(lái)的問(wèn)題是這個(gè)線程是用來(lái)干嘛的，它做了什么？

4. 778號(hào)線程是何方神圣

到這里要給大家一點(diǎn)遺憾了，778號(hào)線程已經(jīng)退出了，棧空間都被釋放了，在dump中不可能找到它生前做了什么，不過(guò)最起碼我們知道如下幾點(diǎn)信息：

它是一個(gè)由 C# 創(chuàng)建的托管線程
它是一個(gè)非線程池線程
它肯定是某種原因意外退出的

要想知道這個(gè)線程生前做了什么，最好的辦法就是用 perfview 捕獲線程創(chuàng)建和退出的 ETW 事件，到那一天定會(huì)水落石出！！！

四：總結(jié)

這次生產(chǎn)事故，我感覺(jué)用戶和CLR都有責(zé)任，托管線程的棧空間都釋放了，為什么 CLR 在觸發(fā) GC 時(shí)還要去爬它的棧導(dǎo)致崩潰的發(fā)生，這真的是一個(gè)很有意思的dump。

總結(jié)

以上是生活随笔為你收集整理的记一次 .NET 某新能源材料检测系统崩溃分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：青桔单车在微信扣费吗(汉典青字的基本解释
下一篇： C++ Qt开发：PushButton按