一：背景

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 还是比较新的，所以先建议朋友换写法观察看看。