为什么有些本机线程在我的代码中有一个没有源的堆栈跟踪

本文关键字:有一个 堆栈 跟踪 代码 本机 线程 我的 为什么 | 更新日期: 2023-09-27 18:13:08

我有一个c# . net 4.5应用程序,它大量使用任务并行库,在运行数天后,最终导致线程短缺。

当我从AdPlus中抓取HANG转储并通过Visual Studio查看线程时,我看到43个线程在我的代码中没有明显的起源:

ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes 
ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes 
kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

为什么这些线程在堆栈跟踪中没有显示托管源?

为什么有些本机线程在我的代码中有一个没有源的堆栈跟踪

给定进程中的所有线程,甚至是TPL线程都有这个启动过程。当你启动一个线程运行时,CLR最终会调用OS来启动一个线程。你看到的是线程在启动时执行的函数。如果挂起任何托管进程,您将看到在堆栈底部存在非托管调用。你看不到托管启动过程的原因是,每个线程都有自己的堆栈,由操作系统在创建线程时创建。

例如:

for (int i = 0; i < 10; i++)
{
    Thread t = new Thread(new ThreadStart(()=>Thread.Sleep(100000)));
    t.Start();
}
Console.ReadKey();

然后使用WinDbg进入进程,并查看其中一个睡眠线程,给出一个调用堆栈,看起来像这样(所有线程在底部都有相同的两个函数,我只是在这个练习中转储一个):

0:012> !dumpstack
OS Thread Id: 0x3694 (12)
Current frame: ntdll!ZwDelayExecution+0xa
Child-SP         RetAddr          Caller, Callee
000000001dc8ea70 000007fefd1c1203 KERNELBASE!SleepEx+0xab, calling ntdll!NtDelayExecution
000000001dc8eae0 000007fefd1c38fb KERNELBASE!SleepEx+0x12d, calling ntdll!RtlActivateActivationContextUnsafeFast
000000001dc8eb10 000007fed860a888 clr!CExecutionEngine::ClrSleepEx+0x29, calling KERNEL32!SleepExStub
000000001dc8eb40 000007fed874d483 clr!Thread::UserSleep+0x7c, calling clr!ClrSleepEx
000000001dc8eba0 000007fed874d597 clr!ThreadNative::Sleep+0xb7, calling clr!Thread::UserSleep
[... removed some frames for clarity ...]
000000001dc8f6f0 000007fed874fcb6 clr!Thread::intermediateThreadProc+0x7d
000000001dc8faf0 000007fed874fc9f clr!Thread::intermediateThreadProc+0x66, calling clr!alloca_probe
000000001dc8fb30 0000000077195a4d KERNEL32!BaseThreadInitThunk+0xd
000000001dc8fb60 00000000773cb831 ntdll!RtlUserThreadStart+0x1d

作为参考,这是包含我们转储堆栈的线程的Thread对象:

0:012> !do 2a23e08
Name:        System.Threading.Thread
MethodTable: 000007fed76522f8
EEClass:     000007fed7038200
Size:        96(0x60) bytes
File:        C:'Windows'Microsoft.Net'assembly'GAC_64'mscorlib'v4.0_4.0.0.0__b77a5c561934e089'mscorlib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007fed763eca8  4000765        8 ....Contexts.Context  0 instance 0000000000000000 m_Context
000007fed765a958  4000766       10 ....ExecutionContext  0 instance 0000000000000000 m_ExecutionContext
000007fed7650e08  4000767       18        System.String  0 instance 0000000000000000 m_Name
000007fed76534a8  4000768       20      System.Delegate  0 instance 0000000000000000 m_Delegate
000007fed7655390  4000769       28 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentCulture
000007fed7655390  400076a       30 ...ation.CultureInfo  0 instance 0000000000000000 m_CurrentUICulture
000007fed76513e8  400076b       38        System.Object  0 instance 0000000000000000 m_ThreadStartArg
000007fed7654a00  400076c       40        System.IntPtr  1 instance          24a5ed0 DONT_USE_InternalThread
000007fed7653980  400076d       48         System.Int32  1 instance                2 m_Priority
000007fed7653980  400076e       4c         System.Int32  1 instance               12 m_ManagedThreadId
000007fed7658c48  400076f       50       System.Boolean  1 instance                1 m_ExecutionContextBelongsToOuterScope
000007fed7672e70  4000770      378 ...LocalDataStoreMgr  0   shared           static s_LocalDataStoreMgr
                                 >> Domain:Value  00000000005f40b0:NotInit  <<
000007fed7672df0  4000771        8 ...alDataStoreHolder  0   shared         TLstatic s_LocalDataStore
                                  >> Thread:Value <<

System.IntPtr(又名DONT_USE_InternalThread)持有指向OS线程的指针。(我猜这可能是CreateThread的句柄,但我没有调查太多)


(编者注意:brillant是故意这样拼写的。