.NET應用程序因GC線程死鎖而掛起

Question

我們的應用程序存在一個問題，該問題混合使用了托管（C＃）和非托管（C ++）代碼。 基本上，我們有一個exe來調用一堆程序集，而其中一個程序集是C ++庫的MC ++包裝器。 該應用程序是一個控制台應用程序。 大多數情況下，它可以正常工作，但偶爾掛起，沒有任何錯誤或異常。

使用內存轉儲和符號，我們已經能夠在WinDbg中進行一些診斷，但是我不確定自己看到的是死鎖還是死鎖。 我已經搜索了堆棧中出現的CLR方法名稱，但是還沒有找到一個線程試圖分配內存並被GC死鎖的情況。

到目前為止，我已經嘗試過使用sos，sosex，psscor4擴展名的WinDbg。 有趣的是，sosex具有檢查死鎖的命令（！dlk），但它沒有報告死鎖。

發布代碼非常困難，因為它是一個大型而復雜的應用程序。 .NET 3.5和4.0程序集混合在一起。 托管和非托管代碼中都有線程。

如果有人可以查看堆棧跟蹤並確認這是GC線程可能造成的死鎖，我會提出建議。 甚至更好，如果您可以建議使用其他方法調試使用C＃和MC ++的.NET應用程序中的死鎖/掛起。

這是我到目前為止的內容：

應用程序掛起時的線程列表：（！threads）

ThreadCount:      8
UnstartedThread:  0
BackgroundThread: 5
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                           PreEmptive                                                   Lock
       ID  OSID        ThreadOBJ     State GC       GC Alloc Context                  Domain           Count APT Exception
   0    1   de0 00000000008069f0      a020 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 MTA
   2    2  2130 000000000080bd30      b220 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 MTA (Finalizer)
   4    3  14fc 000000001d182880   200b020 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 MTA
   5    4  20d0 000000001d18b400      b220 Enabled  0000000000000000:0000000000000000 00000000007fa280     2 MTA (GC)
   6    5  18a8 000000001d19f6a0      b020 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 MTA
   7    6  18a0 000000001d1c6f10       220 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 Ukn
   8    7  12f4 000000001d1c1ee0       220 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 Ukn
  10    8  2170 000000001d1c2ad0       220 Enabled  0000000000000000:0000000000000000 00000000007fa280     0 Ukn

       OSID     Special thread type
    1   2570    DbgHelper 
    2   2130    Finalizer 
    5   20d0    SuspendEE 
   12   1890    GC

這是GC線程的堆棧如下所示：

OS Thread Id: 0x1890 (12)
Child-SP         RetAddr          Call Site
0000000023e9f898 000000007799e4e8 ntdll!ZwWaitForSingleObject+0xa
0000000023e9f8a0 000000007799e3db ntdll!RtlpWaitOnCriticalSection+0xe8
0000000023e9f950 000007fef95d603e ntdll!RtlEnterCriticalSection+0xd1
0000000023e9f980 000007fef947bc41 clr!UnsafeEEEnterCriticalSection+0x1f
0000000023e9f9b0 000007fef947613a clr!CrstBase::Enter+0x1a1
0000000023e9f9f0 000007fef95da3a2 clr!ThreadStore::LockThreadStore+0x9a
0000000023e9fa20 000007fef9679675 clr!WKS::GCHeap::SuspendEE+0x82
0000000023e9fb20 000007fef9677eb2 clr!WKS::gc_heap::bgc_suspend_EE+0x25
0000000023e9fb50 000007fef98455b0 clr!WKS::gc_heap::background_mark_phase+0x236
0000000023e9fbb0 000007fef9677b76 clr! ?? ::FNODOBFM::`string'+0x9f85d
0000000023e9fc00 00000000773d652d clr!WKS::gc_heap::gc_thread_function+0xd3
0000000023e9fc30 000000007797c521 KERNEL32!BaseThreadInitThunk+0xd
0000000023e9fc60 0000000000000000 ntdll!RtlUserThreadStart+0x1d

在我看來，GC線程正在等待關鍵部分。 我們能夠找到關鍵部分的地址，然后找到它的所有者線程（！critsec）。 所有者線程的堆棧如下所示。 我已對其進行了修剪，以使其簡短。 （！dumpstack）

OS Thread Id: 0x20d0 (5)
Child-SP         RetAddr          Call Site
000000001fc5dd38 000007fefe0510dc ntdll!ZwWaitForSingleObject+0xa
000000001fc5dd40 000007fef9478817 KERNELBASE!WaitForSingleObjectEx+0x79
000000001fc5dde0 000007fef94787c0 clr!CLREvent::WaitEx+0x170
000000001fc5de20 000007fef947866b clr!CLREvent::WaitEx+0xf8
000000001fc5de80 000007fef967a15b clr!CLREvent::WaitEx+0x5e
000000001fc5df20 000007fef967a001 clr!WKS::gc_heap::user_thread_wait+0x49
000000001fc5df50 000007fef95dbb4e clr! ?? ::FNODOBFM::`string'+0x9fcc4
000000001fc5e030 000007fef95da22e clr!WKS::GCHeap::GarbageCollectGeneration+0x14e
000000001fc5e080 000007fef95d9e4e clr!WKS::gc_heap::try_allocate_more_space+0x25f
000000001fc5e150 000007fef95d9fc8 clr!WKS::GCHeap::Alloc+0x7e
000000001fc5e180 000007fef947407c clr!AllocateArrayEx+0xa6b
000000001fc5e2f0 000007fef8555b75 clr!JIT_NewArr1+0x45c
000000001fc5e4c0 000007fef8561103 mscorlib_ni!System.Reflection.CustomAttributeData.GetCustomAttributeRecords(System.Reflection.RuntimeModule, Int32)+0x115
000000001fc5e590 000007fef855db55 mscorlib_ni!System.Reflection.CustomAttribute.IsCustomAttributeDefined(System.Reflection.RuntimeModule, Int32, System.RuntimeType, Boolean)+0x103
000000001fc5e720 000007fef856c8ac mscorlib_ni!System.Reflection.CustomAttribute.IsDefined(System.RuntimeType, System.RuntimeType, Boolean)+0x75
000000001fc5e770 000007fef857fe46 mscorlib_ni!System.Enum.InternalFormat(System.RuntimeType, System.Object)+0x2c
000000001fc5e7b0 000007fef8554f3b mscorlib_ni!System.Text.StringBuilder.AppendFormat(System.IFormatProvider, System.String, System.Object[])+0x2e6
000000001fc5e850 000007ff03c640fc mscorlib_ni!System.String.Format(System.IFormatProvider, System.String, System.Object[])+0x7b
000000001fc5e8b0 000007ff03c638a6 MyLibrary1!NumberCache.NumberEntry.ToString()+0x26c

Answer 1

第二個調用堆棧中的這一行看起來可疑：

000000001fc5df50 000007fef95dbb4e clr! ?? ::FNODOBFM::`string'+0x9fcc4 

看看偏移地址有多大，我看不到任何模塊名稱，您是否缺少一些符號？

該庫中可能有一個終結器導致問題。

Answer 2

不是一個大專家，但只是好奇並想知道finalizer線程是否在鎖定某些資源時崩潰了（我的意思是finalizer線程中未處理的異常），而GC線程正在嘗試獲取該線程？