如何洞察 .NET程序 非托管句柄泄露

发表于:2023-7-12 09:42

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:一线码农聊技术    来源:一线码农聊技术

  一:讲故事
  很多朋友可能会有疑问,C# 是一门托管语言,怎么可能会有非托管句柄泄露呢? 其实一旦 C# 程序与 C++ 语言交互之后,往往就会被后者拖入非托管泥潭,让我们这些调试者被迫探究 非托管领域问题。
  二:非托管句柄泄露
  1. 测试案例
  为了方便讲述,我们上一个 Event 泄露的案例,使用 C# 调用 C++ ,然后让 C++ 产生 bug 导致句柄泄露。
  先看一下 C++ 代码:
  extern "C"
  {
   _declspec(dllexport) void CSharpCreateEvent();
  }
  #include "iostream"
  #include <Windows.h>
  using namespace std;
  void CSharpCreateEvent()
  {
   HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
   printf("\nEvent句柄值: %#08x ", hEvent);
  }
  然后导出一个 CSharpCreateEvent 方法给 C# 使用。
  internal class Program
      {
          [DllImport("Example_20_1_5", CallingConvention = CallingConvention.Cdecl)]
          extern static void CSharpCreateEvent();
          static void Main(string[] args)
          {
              try
              {
                  while (true)
                  {
                      Task.Run(() =>
                      {
                          CSharpCreateEvent();
                      });
                      Thread.Sleep(10);
                  }
              }
              catch (Exception ex)
              {
                  Console.WriteLine(ex.Message);
              }
              Console.ReadLine();
          }
      }
  程序跑起来后,在任务管理器中会发现这个句柄在不断的上涨,截图如下:
  2. 到底是谁在泄露
  如果你的生产环境可以用 WinDbg 附加进程,那用它就可以轻松解决,可以借助 !handle 命令看一下泄露的句柄类型。
  0:004> !handle 
  ...
  Handle 16fc
    Type          Event
  1411 Handles
  Type            Count
  None            6
  Event           1337
  File            16
  Directory       4
  Mutant          3
  WindowStation   2
  Semaphore       5
  Key             10
  Thread          8
  Desktop         1
  IoCompletion    5
  TpWorkerFactory 3
  ALPC Port       1
  WaitCompletionPacket 10
  从统计信息看,当前 Event 高达 1337 个,看样子程序存在 Event 泄露,接下来我们就要洞察到底是谁分配的 Event,如果能找到分配 Event 的线程栈,那这个问题就会迎刃而解,对吧,有 WinDbg 在,方圆3公里的bug都要移民,追踪调用栈可以使用 WinDbg 提供的 !htrace 命令。
  它的原理很简单,一句话表示就是:挖出现在时间点和快照之间那些没有被 free 处理的 handle 调用栈,结果一清二楚,参考代码如下:
  0:011> !htrace -enable
  Handle tracing enabled.
  Handle tracing information snapshot successfully taken.
  0:011> g
  (e14.90c0): Break instruction exception - code 80000003 (first chance)
  eax=006f2000 ebx=00000000 ecx=7777dfe0 edx=10088020 esi=7777dfe0 edi=7777dfe0
  eip=77744e50 esp=0811f97c ebp=0811f9a8 iopl=0         nv up ei pl zr na pe nc
  cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
  ntdll!DbgBreakPoint:
  77744e50 cc              int     3
  0:007> !htrace -diff
  Handle tracing information snapshot successfully taken.
  0xad new stack traces since the previous snapshot.
  Ignoring handles that were already closed...
  Outstanding handles opened since the previous snapshot:
  --------------------------------------
  Handle = 0x0000199c - OPEN
  Thread ID = 0x000017c8, Process ID = 0x00000e14
  0x4ac3d761: +0x4ac3d761
  0x4aa0d9f5: +0x4aa0d9f5
  0x6674d9c4: +0x6674d9c4
  0x66547f33: +0x66547f33
  0x6654901a: +0x6654901a
  0x776c17c3: +0x776c17c3
  0x776c11b9: +0x776c11b9
  0x665438c9: +0x665438c9
  0x665432bd: +0x665432bd
  0x66725089: +0x66725089
  0x66724c73: +0x66724c73
  0x66724c1e: +0x66724c1e
  0x77742f7c: ntdll!NtCreateEvent+0x0000000c
  0x770f5746: KERNELBASE!CreateEventExW+0x00000056
  0x770e2b04: KERNELBASE!CreateEventW+0x00000024
  *** WARNING: Unable to verify checksum for D:\skyfly\20.20230628\src\Example\Example_20_1_4\bin\x86\Debug\net6.0\Example_20_1_5.DLL
  0x6ac91755: Example_20_1_5!CSharpCreateEvent+0x00000035
  --------------------------------------
  ...
  Displayed 0xaa stack traces for outstanding handles opened since the previous snapshot.
  从卦中短暂的时间内快照之间有 170 个句柄没有被释放,而且从调用栈看是 Example_20_1_5!CSharpCreateEvent 方法所致,但这里有一个问题,虽然有非托管栈,但没有看到任何托管部分,那怎么办呢?
  3. 如何洞察到托管栈
  其实这个问题很简单,既然都 WinDbg 附加了,干脆用 bp 下断点,后续泄露之时必然会被命中,然后通过 !clrstack 或者 k 观察线程栈即可,有了思路就开干。
  :007> bp Example_20_1_5!CSharpCreateEvent "k; gc"
  breakpoint 0 redefined
  0:007> g
   # ChildEBP RetAddr      
  00 0848f9e4 080674f3     Example_20_1_5!CSharpCreateEvent [D:\skyfly\20.20230628\src\Example\Example_20_1_5\Example_20_1_5.cpp @ 15] 
  WARNING: Frame IP not in any known module. Following frames may be wrong.
  01 0848f9e4 0806748b     0x80674f3
  02 0848f9f0 0806e3dd     Example_20_1_4!Example_20_1_4.Program.<>c.<Main>b__1_0+0x1b
  03 0848f9fc 0806e38d     System_Private_CoreLib!System.Threading.Tasks.Task.InnerInvoke+0x3d
  04 0848fa04 0806e307     System_Private_CoreLib!System.Threading.Tasks.Task.<>c.<.cctor>b__272_0+0xd
  05 0848fa2c 0806e072     System_Private_CoreLib!System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop+0x37
  06 0848fa94 0806c49f     System_Private_CoreLib!System.Threading.Tasks.Task.ExecuteWithThreadLocal+0x82
  07 0848faec 6b22f2bc     System_Private_CoreLib!System.Threading.ThreadPoolWorkQueue.Dispatch+0x1bf
  08 0848fb88 6b216595     System_Private_CoreLib!System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart+0xdc [/_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs @ 63] 
  09 0848fb98 6c00c30f     System_Private_CoreLib!System.Threading.Thread.StartCallback+0x35 [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 106] 
  0a 0848fba4 6bf5c07b     coreclr!CallDescrWorkerInternal+0x34
  0b 0848fbd8 6bf6799a     coreclr!CallDescrWorkerWithHandler+0x66 [D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp @ 69] 
  0c 0848fc20 6bff619b     coreclr!DispatchCallSimple+0x7f [D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp @ 220] 
  0d 0848fc44 6bf7c7df     coreclr!ThreadNative::KickOffThread_Worker+0x4b [D:\a\_work\1\s\src\coreclr\vm\comsynchronizable.cpp @ 158] 
  0e (Inline) --------     coreclr!ManagedThreadBase_DispatchInner+0x3d [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 7321] 
  0f 0848fcc8 6bf7c70f     coreclr!ManagedThreadBase_DispatchMiddle+0x8c [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 7365] 
  10 0848fd20 6bf1116f     coreclr!ManagedThreadBase_DispatchOuter+0x62 [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 7543] 
  11 (Inline) --------     coreclr!ManagedThreadBase_FullTransition+0x21 [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 7569] 
  12 (Inline) --------     coreclr!ManagedThreadBase::KickOff+0x21 [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 7604] 
  13 0848fd54 755b00f9     coreclr!ThreadNative::KickOffThread+0x7f [D:\a\_work\1\s\src\coreclr\vm\comsynchronizable.cpp @ 230] 
  14 0848fd64 77737bbe     KERNEL32!BaseThreadInitThunk+0x19
  15 0848fdc0 77737b8e     ntdll!__RtlUserThreadStart+0x2f
  16 0848fdd0 00000000     ntdll!_RtlUserThreadStart+0x1b
  ...
  从卦中看,一切都非常明白,这里再补充一点,如果想中途再产生 快照,可以用 -snapshot 命令创建一个初始点,参考如下:
  0:007> !htrace -snapshot
  Handle tracing information snapshot successfully taken.
  三:总结
  handle 泄露也是一个比较难搞的问题,难点在于生产环境可能不让你用 WinDbg 这种侵入方式,但问题还得要解决,必须创造条件上,当前除了 WinDbg 还没有找到其他方式,有机会再研究下吧。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号