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

反转基因福娃  论坛元老 | 2024-5-27 11:03:49 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 1636|帖子 1636|积分 4908

一：背景

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 还是比力新的，所以先发起朋侪换写法观察看看。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看，没有账号？立即注册

x
回复

举报

0 个回复

倒序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

反转基因福娃

论坛元老
这个人很懒什么都没写!

楼主热帖

标签云

集成商 AI 运维 CIO 存储 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表