糙昧邵 发表于 2025-6-16 11:46:23

记一次 .NET 某SaaS版CRM系统 崩溃分析

一:背景

1. 讲故事

调试训练营里的一位学员前些天找到我,说他们跑在k8s中的程序崩掉了不知道怎么回事?日志也没有记录到,让我帮他看看,dump也抓到了,既然抓到了那就看看吧。
二:程序为什么会崩溃

1. 崩溃原因

linux 上的崩溃分析没有windows上那么方便,但还是可以分析的,先通过 !t 看下是不是托管层崩溃导致的,输出如下:
0:005> !t
ThreadCount:      132
UnstartedThread:0
BackgroundThread: 129
PendingThread:    0
DeadThread:       2
Hosted Runtime:   no
                                                                                                            Lock
DBG   ID   OSID ThreadOBJ         State GC Mode   GC Alloc Context                  Domain         Count Apt Exception
   0    1      1 0000557F7C7518B02020020 Preemptive0000000000000000:0000000000000000 0000557f7c71d0c0 -00001 Ukn
   5    2      b 0000557F7C6A5020    21222 Cooperative 00007FBB74F57F90:00007FBB74F59DF0 0000557f7c71d0c0 -00001 Ukn (Finalizer) System.NullReferenceException 00007fbb74f05230
   6    4      d 0000557F7CB53D40    21220 Preemptive0000000000000000:0000000000000000 0000557f7c71d0c0 -00001 Ukn
   7    6      f 0000557F7CB5C0703021220 Preemptive0000000000000000:0000000000000000 0000557f7c71d0c0 -00001 Ukn (Threadpool Worker)
   ...从卦中数据来看,原来是终结器线程 抛了 空引用异常,这个还是挺有意思的。。。可遇不可求,赶紧切过去用 !pe 命令观察。
0:005> ~5s
libc_so!wait4+0x57:
00007fca`99249c17 483d00f0ffff    cmp   rax,0FFFFFFFFFFFFF000h
0:005> !pe
Exception object: 00007fbb74f05230
Exception type:   System.NullReferenceException
Message:          Object reference not set to an instance of an object.
InnerException:   <none>
StackTrace (generated):
    SP               IP               Function
    00007FCA968E3690 00007FCA6D8DF4A4 System_Runtime_Caching!System.Runtime.Caching.MemoryCache.OnUnhandledException(System.Object, System.UnhandledExceptionEventArgs)+0x24

StackTraceString: <none>
HResult: 80004003

0:005> k
# Child-SP          RetAddr               Call Site
00 00007fca`968e3cb0 00007fca`98ff5635   libc_so!wait4+0x57
01 00007fca`968e3ce0 00007fca`98ff6580   libcoreclr!PROCCreateCrashDump+0x275
02 00007fca`968e3d40 00007fca`98ff422f   libcoreclr!PROCCreateCrashDumpIfEnabled+0x770
03 00007fca`968e3dd0 00007fca`98ff4159 (T) libcoreclr!PROCAbort+0x2f
04 (Inline Function) --------`--------   libcoreclr!PROCEndProcess+0x7c
05 00007fca`968e3df0 00007fca`98cf7121   libcoreclr!TerminateProcess+0x89
06 00007fca`968e3e10 00007fca`98ff81ae   libcoreclr!FinalizerThread::FinalizerThreadStart+0xf1
07 00007fca`968e3e30 00007fca`991ff1f5   libcoreclr!CorUnix::CPalThread::ThreadEntry+0x1fe
08 00007fca`968e3ee0 00007fca`9927eb00   libc_so!pthread_condattr_setpshared+0x515
09 00007fca`968e3f80 ffffffff`ffffffff   libc_so!_clone+0x40
0a 00007fca`968e3f88 00000000`00000000   0xffffffff`ffffffff从卦象看,应该是微软的 MemoryCache 导致的空引用异常,然后终结器线程进入自爆状态,这个就更有意思了。。。 接下来观察 OnUnhandledException 方法到底发生了什么。
2. OnUnhandledException 怎么啦

要想看到 OnUnhandledException 中的源代码,可以将dll给dump出来,C# 代码如下:
      // System.Runtime.Caching, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
      // System.Runtime.Caching.MemoryCache
      private void OnUnhandledException(object sender, UnhandledExceptionEventArgs eventArgs)
      {
            if (eventArgs.IsTerminating)
            {
                Dispose();
            }
      }我去,就一个if也能抛异常,这也太狗血了。。。既然抛了空引用异常,从伦理上讲应该就是 eventArgs=null 导致的,那是不是的呢?这个就需要观察崩溃处的汇编代码了,即 !U 00007FCA6D8DF4A4,输出如下:
0:005> !U 00007FCA6D8DF4A4
Normal JIT generated code
System.Runtime.Caching.MemoryCache.OnUnhandledException(System.Object, System.UnhandledExceptionEventArgs)
ilAddr is 00007FBAD90D54D8 pImport is 000001BA2E289160
Begin 00007FCA6D8DF480, size 43

/_/src/libraries/System.Runtime.Caching/src/System/Runtime/Caching/MemoryCache.cs @ 247:
00007fca`6d8df480 55            push    rbp
00007fca`6d8df481 4883ec20      sub   rsp,20h
00007fca`6d8df485 488d6c2420      lea   rbp,
00007fca`6d8df48a 48897df8      mov   qword ptr ,rdi
00007fca`6d8df48e 488975f0      mov   qword ptr ,rsi
00007fca`6d8df492 488955e8      mov   qword ptr ,rdx
00007fca`6d8df496 488b7de8      mov   rdi,qword ptr
00007fca`6d8df49a 48b888451023ca7f0000 mov rax,7FCA23104588h
>>> 00007fca`6d8df4a4 393f            cmp   dword ptr ,edi
00007fca`6d8df4a6 ff10            call    qword ptr
00007fca`6d8df4a8 85c0            test    eax,eax
00007fca`6d8df4aa 7410            je      00007fca`6d8df4bc

/_/src/libraries/System.Runtime.Caching/src/System/Runtime/Caching/MemoryCache.cs @ 249:
00007fca`6d8df4ac 488b7df8      mov   rdi,qword ptr
00007fca`6d8df4b0 48b810890d23ca7f0000 mov rax,7FCA230D8910h
00007fca`6d8df4ba ff10            call    qword ptr

/_/src/libraries/System.Runtime.Caching/src/System/Runtime/Caching/MemoryCache.cs @ 251:
00007fca`6d8df4bc 90            nop
00007fca`6d8df4bd 4883c420      add   rsp,20h
00007fca`6d8df4c1 5d            pop   rbp
00007fca`6d8df4c2 c3            ret从卦中的 >>> 可以看出,此处即为崩溃的汇编代码 cmp   dword ptr ,edi,经常看 C# 汇编的朋友应该非常熟悉,这是 JIT 生成的一段 可空判断的保护代码,如果你还想更进一步确认的话,刚好上周在训练营里讲到了 linux 的 x64 调用协定,即 linux 会用 6个寄存器 rdi, rsi, rdx, rcx, r8, r9 来传送方法的前六个参数,根据刚才汇编可以看到,rdi 来源于 rdx,这个参数就是 this 指针,也就完美的佐证了。
接下来我们观察下 OnUnhandledException 方法来自于何处,分析代码之后,发现是 MemoryCache 类下的初始化方法 InitDisposableMembers 中处理的,将其注册到 AppDomain 全局异常兜底中,截图如下:

问题到此就真相大白了,如何处理呢?
3. 我该如何解决

很难想到 MemoryCache 还会存在这种新级bug,既然是第三方的,我们也不好直接修改源代码,能做的就是升级升级再升级,我们将 Version=4.0.0.0 直接干到最新的Version=9.0.6,再次观察,结果发现已经 物是人非 了,OnUnhandledException 也没有了,InitDisposableMembers 也重构了,截图如下:

这个问题虽然解决了,但可能有些朋友会有一个疑问,为什么是终结器线程走这段逻辑,这块其实就是考验你的C# 知识,哈哈,我当年是从 CLR Via C# 中学到的。
大概是这样的,如果一个 Task 中包含了一个隐含的未处理异常,最后当终结器被析构时会抛出未处理异常,这个异常就会被全局的 AppDomain.UnhandledException 拦截,在 UnhandledException 处理的过程中又不幸再次抛出异常,最终导致程序的崩溃。
三:总结

这次生产事故是由于微软的 MemoryCache 类下的一个新手级bug导致,确实有点让人震惊,所以这个世界或许还真是一个巨大的草台班子。。。


来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
页: [1]
查看完整版本: 记一次 .NET 某SaaS版CRM系统 崩溃分析