記一次 .NET某企業數字化平臺 崩潰分析

一:背景

1. 講故事

前些天羣裏有一個朋友說他們軟件會偶發崩潰,想分析看看是怎麼回事,所幸的是自己會抓dump文件,有了dump就比較好分析了,接下來我們開始吧。

二:WinDbg 分析

1. 程序爲什麼會崩潰

windbg 還是非常強大的,當你雙擊打開的時候會自動幫你定位過去展示崩潰時刻的寄存器和線程棧上下文,都省了 !analyze -v 命令分析了,輸出如下:


Loading unloaded module list
...............
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1dc.774): Stack overflow - code c00000fd (first/second chance not available)
For analysis of this file, run !analyze -v
000007f8`93111989 837c243000      cmp     dword ptr [rsp+30h],0 ss:0000007b`e7894160=00000000

從卦中可以看到有一個 Stack overflow 異常,說明當前棧溢出了,有點意思。

2. 棧溢出了嗎

如果你想探究下棧溢出也是可以的,用 rsp 比較下 !teb 中的 StackLimit 值。


0:019> r rsp
rsp=0000007be7894130

0:019> !teb
TEB at 000007f6cd664000
    ExceptionList:        0000000000000000
    StackBase:            0000007be7a10000
    StackLimit:           0000007be7891000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 000007f6cd664000
    EnvironmentPointer:   0000000000000000
    ClientId:             00000000000001dc . 0000000000000774
    RpcHandle:            0000000000000000
    Tls Storage:          0000007be84b5b90
    PEB Address:          000007f6cd7af000
    LastErrorValue:       0
    LastStatusValue:      c0000302
    Count Owned Locks:    0
    HardErrorMode:        0

0:019> !address -f:Stack

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
--------------------------------------------------------------------------------------------------------------------------
      7b`e7890000       7b`e7891000        0`00001000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~19; 1dc.774]
      7b`e7891000       7b`e7a10000        0`0017f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~19; 1dc.774]

從卦中看 PAGE_GUARD 頁已經抹掉了,這就表示當前的 rsp 已經進入到這個 0x3000 大小的 PAGE_GUARD 頁面裏去了。

有些朋友可能會有一個疑問,這個異常是怎麼被界定爲 StackOverflowException 的呢? 如果你瞭解哨兵頁就比較簡單了,一旦rsp進了這個哨兵頁,在這裏拋出的異常會被界定爲 c00000fd,最後這個異常會被 coreclr 的 MapWin32FaultToCOMPlusException 方法強制轉爲託管的 StackOverflowException 異常,這個都是有源碼支撐的。


EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 000007f8ed571a90 (coreclr!MetaDataImport::Enum+0x0000000000000030)
   ExceptionCode: c00000fd (Stack overflow)
  ExceptionFlags: 00000001
NumberParameters: 2
   Parameter[0]: 0000000000000001
   Parameter[1]: 0000007be7893f38

DWORD MapWin32FaultToCOMPlusException(EXCEPTION_RECORD *pExceptionRecord)
{
    switch (pExceptionRecord->ExceptionCode)
    {
		...
        case STATUS_STACK_OVERFLOW:
            return (DWORD) kStackOverflowException;
        ....

		default:
            return kSEHException;
    }
}

3. 到底誰給弄溢出了

現在我們定位到的線程就是棧溢出線程,使用 kc 觀察調用棧,輸出如下:


0:019> kc
 # Call Site
00 System_Private_CoreLib!System.Reflection.RuntimeCustomAttributeData.GetCustomAttributeRecords
01 System_Private_CoreLib!System.Reflection.CustomAttribute.AddCustomAttributes
02 System_Private_CoreLib!System.Reflection.CustomAttribute.GetCustomAttributes
03 System_Private_CoreLib!System.Attribute.GetCustomAttributes
...
0c SqlSugar!SqlSugar.MemberExpressionResolve..ctor
0d SqlSugar!SqlSugar.BaseResolve.Start
0e SqlSugar!SqlSugar.BinaryExpressionResolve.Right
0f SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary
10 SqlSugar!SqlSugar.BinaryExpressionResolve.Other
11 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor
12 SqlSugar!SqlSugar.BaseResolve.Start
13 SqlSugar!SqlSugar.BinaryExpressionResolve.Right
14 SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary
15 SqlSugar!SqlSugar.BinaryExpressionResolve.Other
16 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor
17 SqlSugar!SqlSugar.BaseResolve.Start
...

默認的 kc 只能顯示 255 個線程棧,在棧溢出場景下沒辦法完全展開,不管怎麼樣從棧看貌似是 SqlSugar 導致的棧溢出,那它是這次災難的罪魁禍首嗎?

4. SqlSugar 是禍首嗎

要想找到這個答案,需要看下 SqlSugar 是被怎樣的用戶代碼調用的,有兩種辦法,要麼在 k 上設置 StackPtr,要麼設置最大的棧個數 0xffff ,這裏選擇後者。


0:019> kc 0xffff
 # Call Site
....
145b SqlSugar!SqlSugar.ExpressionContext.Resolve
145c SqlSugar!SqlSugar.QueryBuilder.GetExpressionValue
145d SqlSugar!SqlSugar.QueryableProvider<xxx>._Where
145e SqlSugar!SqlSugar.QueryableProvider<xxxx>.Where
145f SqlSugar!SqlSugar.SimpleClient<xxx>.GetListAsync
1460 xxx!xxx.TSqlSugar.xxx<xxx.Entities.Quality.xxxSummaryEntity>.<QueryAsync>d__37.MoveNext
1461 System_Private_CoreLib!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<<QueryAsync>d__37>
1462 xxx!xxx.TSqlSugar.BaseRepository<xxx.xxxSummaryEntity>.QueryAsync
1463 xxx!xxxxCalculateService.<xxxnRate>d__26.MoveNext
...

從卦中可以看到有一個 xxxxCalculateService 用戶類調用了 QueryAsync 方法,接下來直接到源碼定位,截圖如下:

這段代碼乍一看貌似沒有問題,但仔細看還是有一些端倪的,對,就是當 diffMonth 很大時, expressionable 就會累計出很多的 And 條件,在QueryAsync的時候底層的 SqlSugar 在拆解 expressionable 的過程中拋出了異常。

5. SqlSugar 真的在拆解中異常了嗎

拆解表達式樹的代碼太難了,我真的看不懂,在這種情況下如何尋找突破口呢?這裏可以逆向的想一想,既然是拆解,自然就會產生很多小段sql,所以直接到 託管堆中看下當前的 string 情況即可。


0:019> !strings
Address            Gen    Length   Value
---------------------------------------
...
0000007bc15a0240   LOH     97005   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc15cf850   LOH     97005   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc15fee60   LOH     97009   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc162e478   LOH     97009   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc165da90   LOH     97074   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc168d130   LOH     97099   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc16bc800   LOH     97099   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc16ebed0   LOH     97103   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc171b5a8   LOH     97103   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
0000007bc174ac80   LOH     97113   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
....
---------------------------------------
39498 strings

從卦中看真厲害,有很多 近10w 左右的 string,拆開 string 看正是And中的表達式樹裏的字段,這裏就不展示了。

三:總結

這次程序崩潰主要是朋友的奇葩寫法導致 SqlSugar 在拆解表達式樹的時候拋了異常,個人覺得底層最好把 遞歸 改成 循環 之類的避免棧溢出,看了下SqlSugar版本 File version: 5.1.4.143 還是比較新的,所以先建議朋友換寫法觀察看看。

图片名称
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章