记一次 .NET某企业数字化平台 崩溃分析

大脸怪

一：背景

1. 讲故事

前些天群里有一个朋友说他们软件会偶发崩溃，想分析看看是怎么回事，所幸的是自己会抓dump文件，有了dump就比较好分析了，接下来我们开始吧。
二：WinDbg 分析

1. 程序为什么会崩溃

windbg 还是非常强大的，当你双击打开的时候会自动帮你定位过去展示崩溃时刻的寄存器和线程栈上下文，都省了 !analyze -v 命令分析了，输出如下：

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

复制代码

从卦中可以看到有一个 Stack overflow 异常，说明当前栈溢出了，有点意思。
2. 栈溢出了吗

如果你想探究下栈溢出也是可以的，用 rsp 比较下 !teb 中的 StackLimit 值。

1. 0:019> r rsp
2. rsp=0000007be7894130
4. 0:019> !teb
5. TEB at 000007f6cd664000
6.     ExceptionList:        0000000000000000
7.     StackBase:            0000007be7a10000
8.     StackLimit:           0000007be7891000
9.     SubSystemTib:         0000000000000000
10.     FiberData:            0000000000001e00
11.     ArbitraryUserPointer: 0000000000000000
12.     Self:                 000007f6cd664000
13.     EnvironmentPointer:   0000000000000000
14.     ClientId:             00000000000001dc . 0000000000000774
15.     RpcHandle:            0000000000000000
16.     Tls Storage:          0000007be84b5b90
17.     PEB Address:          000007f6cd7af000
18.     LastErrorValue:       0
19.     LastStatusValue:      c0000302
20.     Count Owned Locks:    0
21.     HardErrorMode:        0
23. 0:019> !address -f:Stack
25.         BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
26. --------------------------------------------------------------------------------------------------------------------------
27.       7b`e7890000       7b`e7891000        0`00001000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~19; 1dc.774]
28.       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 异常，这个都是有源码支撑的。

1. EXCEPTION_RECORD:  (.exr -1)
2. ExceptionAddress: 000007f8ed571a90 (coreclr!MetaDataImport::Enum+0x0000000000000030)
3.    ExceptionCode: c00000fd (Stack overflow)
4.   ExceptionFlags: 00000001
5. NumberParameters: 2
6.    Parameter[0]: 0000000000000001
7.    Parameter[1]: 0000007be7893f38
9. DWORD MapWin32FaultToCOMPlusException(EXCEPTION_RECORD *pExceptionRecord)
10. {
11.     switch (pExceptionRecord->ExceptionCode)
12.     {
13.                 ...
14.         case STATUS_STACK_OVERFLOW:
15.             return (DWORD) kStackOverflowException;
16.         ....
18.                 default:
19.             return kSEHException;
20.     }
21. }

复制代码

3. 到底谁给弄溢出了

现在我们定位到的线程就是栈溢出线程，使用 kc 观察调用栈，输出如下：

1. 0:019> kc
2. # Call Site
3. 00 System_Private_CoreLib!System.Reflection.RuntimeCustomAttributeData.GetCustomAttributeRecords
4. 01 System_Private_CoreLib!System.Reflection.CustomAttribute.AddCustomAttributes
5. 02 System_Private_CoreLib!System.Reflection.CustomAttribute.GetCustomAttributes
6. 03 System_Private_CoreLib!System.Attribute.GetCustomAttributes
7. ...
8. 0c SqlSugar!SqlSugar.MemberExpressionResolve..ctor
9. 0d SqlSugar!SqlSugar.BaseResolve.Start
10. 0e SqlSugar!SqlSugar.BinaryExpressionResolve.Right
11. 0f SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary
12. 10 SqlSugar!SqlSugar.BinaryExpressionResolve.Other
13. 11 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor
14. 12 SqlSugar!SqlSugar.BaseResolve.Start
15. 13 SqlSugar!SqlSugar.BinaryExpressionResolve.Right
16. 14 SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary
17. 15 SqlSugar!SqlSugar.BinaryExpressionResolve.Other
18. 16 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor
19. 17 SqlSugar!SqlSugar.BaseResolve.Start
20. ...

复制代码

默认的 kc 只能显示 255 个线程栈，在栈溢出场景下没办法完全展开，不管怎么样从栈看貌似是 SqlSugar 导致的栈溢出，那它是这次灾难的罪魁祸首吗？
4. SqlSugar 是祸首吗

要想找到这个答案，需要看下 SqlSugar 是被怎样的用户代码调用的，有两种办法，要么在 k 上设置 StackPtr，要么设置最大的栈个数 0xffff ，这里选择后者。

1. 0:019> kc 0xffff
2. # Call Site
3. ....
4. 145b SqlSugar!SqlSugar.ExpressionContext.Resolve
5. 145c SqlSugar!SqlSugar.QueryBuilder.GetExpressionValue
6. 145d SqlSugar!SqlSugar.QueryableProvider<xxx>._Where
7. 145e SqlSugar!SqlSugar.QueryableProvider<xxxx>.Where
8. 145f SqlSugar!SqlSugar.SimpleClient<xxx>.GetListAsync
9. 1460 xxx!xxx.TSqlSugar.xxx<xxx.Entities.Quality.xxxSummaryEntity>.<QueryAsync>d__37.MoveNext
10. 1461 System_Private_CoreLib!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<<QueryAsync>d__37>
11. 1462 xxx!xxx.TSqlSugar.BaseRepository<xxx.xxxSummaryEntity>.QueryAsync
12. 1463 xxx!xxxxCalculateService.<xxxnRate>d__26.MoveNext
13. ...

复制代码

从卦中可以看到有一个 xxxxCalculateService 用户类调用了 QueryAsync 方法，接下来直接到源码定位，截图如下：

这段代码乍一看貌似没有问题，但仔细看还是有一些端倪的，对，就是当 diffMonth 很大时， expressionable 就会累计出很多的 And 条件，在QueryAsync的时候底层的 SqlSugar 在拆解 expressionable 的过程中抛出了异常。
5. SqlSugar 真的在拆解中异常了吗

拆解表达式树的代码太难了，我真的看不懂，在这种情况下如何寻找突破口呢？这里可以逆向的想一想，既然是拆解，自然就会产生很多小段sql，所以直接到 托管堆中看下当前的 string 情况即可。

1. 0:019> !strings
2. Address            Gen    Length   Value
3. ---------------------------------------
4. ...
5. 0000007bc15a0240   LOH     97005   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
6. 0000007bc15cf850   LOH     97005   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
7. 0000007bc15fee60   LOH     97009   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
8. 0000007bc162e478   LOH     97009   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
9. 0000007bc165da90   LOH     97074   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
10. 0000007bc168d130   LOH     97099   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
11. 0000007bc16bc800   LOH     97099   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
12. 0000007bc16ebed0   LOH     97103   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
13. 0000007bc171b5a8   LOH     97103   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
14. 0000007bc174ac80   LOH     97113   ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
15. ....
16. ---------------------------------------
17. 39498 strings

复制代码

从卦中看真厉害，有很多 近10w 左右的 string，拆开 string 看正是And中的表达式树里的字段，这里就不展示了。
三：总结

这次程序崩溃主要是朋友的奇葩写法导致 SqlSugar 在拆解表达式树的时候抛了异常，个人觉得底层最好把 递归 改成 循环 之类的避免栈溢出，看了下SqlSugar版本 File version: 5.1.4.143 还是比较新的，所以先建议朋友换写法观察看看。

来源:https://www.cnblogs.com/huangxincheng/p/18215055
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！