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

这篇具有很好参考价值的文章主要介绍了如何洞察 .NET程序 非托管句柄泄露。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:背景

1. 讲故事

很多朋友可能会有疑问,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();
        }
    }

程序跑起来后,在任务管理器中会发现这个句柄在不断的上涨,截图如下:

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

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 还没有找到其他方式,有机会再研究下吧。文章来源地址https://www.toymoban.com/news/detail-529198.html

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

到了这里,关于如何洞察 .NET程序 非托管句柄泄露的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 .NET某账本软件 非托管泄露分析

    中秋国庆长假结束,哈哈,在老家拍了很多的短视频,有兴趣的可以上B站观看:https://space.bilibili.com/409524162 ,今天继续给大家分享各种奇奇怪怪的.NET生产事故,希望能帮助大家在未来的编程之路上少踩坑。 话不多说,这篇看一个 .NET程序集泄露 导致的CLR私有堆泄露的案例,

    2024年02月08日
    浏览(15)
  • 记一次 .NET某收银软件 非托管泄露分析

    在我的分析之旅中,遇到过很多程序的故障和杀毒软件扯上了关系,有杀毒软件导致的程序卡死,有杀毒软件导致的程序崩溃,这一篇又出现了一个杀毒软件导致的程序非托管内存泄露,真的是分析多了什么鬼都能撞上。 前几天有位朋友找到过,我他们的程序内存在慢慢的泄

    2024年02月03日
    浏览(14)
  • 记一次 .NET某报关系统 非托管泄露分析

    前段时间有位朋友找到我,说他的程序内存会出现暴涨,让我看下是怎么事情?而且还告诉我是在 Linux 环境下,说实话在Linux上分析.NET程序难度会很大,难度大的原因在于Linux上的各种开源工具主要是针对 C/C++, 和 .NET 一毛钱关系都没有,说到底微软在 Linux 上的调试领域支持

    2024年02月14日
    浏览(21)
  • 记一次 .NET 某医院预约平台 非托管泄露分析

    前几天有位朋友找到我,说他的程序有内存泄露,让我帮忙排查一下,截图如下: 说实话看到 32bit, 1.5G 这些之后,职业敏感告诉我,他这个可能是虚拟地址紧张所致,不管怎么说,有了 Dump 就可以上马分析。 要看是不是虚拟地址紧张,可以用 !address -summary 观察下内

    2024年02月12日
    浏览(18)
  • 记一次 .NET某新能源MES系统 非托管泄露

    前些天有位朋友找到我,说他们的程序有内存泄露,跟着我的错题集也没找出是什么原因,刚好手头上有一个 7G+ 的 dump,让我帮忙看下是怎么回事,既然找到我了那就给他看看吧,不过他的微信头像有点像 二道贩子 ,不管到我这里是不是 三道 ,该分析的还得要分析呀。😄

    2024年02月08日
    浏览(11)
  • PerfView专题 (第十六篇): 如何洞察C#托管堆内存的 "黑洞现象"

    首先声明的是这个 黑洞 是我定义的术语,它是用来表示 内存吞噬 的一种现象,何为 内存吞噬 ,我们来看一张图。 从上面的 卦象图 来看,GCHeap 的 Allocated=852M 和 Committed=16.6G ,它们的差值就是 分配缓冲区=16G ,缓冲区的好处就是用空间换时间,弊端就是会实实在在的侵占内

    2024年02月16日
    浏览(23)
  • 用 perfcollect 洞察 Linux 上.NET程序 CPU爆高

    如果要分析 Linux上的 .NET程序 CPU 爆高,按以往的个性我肯定是抓个 dump 下来做事后分析,这种分析模式虽然不重但也不轻,还需要一定的底层知识,那有没有傻瓜式的 CPU 爆高分析方式呢? 相信有很多朋友知道 B站713事件 ,最终就是用 perf 找到了那个让 cpu 100% 的 lua 函数,截

    2024年02月16日
    浏览(23)
  • 记一次奇怪的文件句柄泄露问题

    记录并分享一下最近工作中遇到的 Too many open files 异常的解决过程。 产品有个上传压缩包并导入配置信息到数据库中的功能,主要流程如下: 用户上传压缩包; 后端解压存放在临时目录,并返回列表给用户; 用户选择需要导入哪些信息; 后端按需插入数据库中,完成后删

    2024年02月05日
    浏览(16)
  • RK3588 MPP解码句柄泄露问题记录

    最近在用瑞芯微3588开发板做一个视频处理的项目,前两天拷机发生了闪退,弹出的问题是“打开文件过多”,经过初步排查定位到是MPP硬解码部分出的问题。 我的MPP解码部分主要用来读取网络相机rtsp流,主要参考了一个github项目GitHub - MUZLATAN/ffmpeg_rtsp_mpp: ffmpeg 拉取rtsp h264流

    2024年02月09日
    浏览(49)
  • PerfView 洞察C#托管堆内存 "黑洞现象"

    首先声明的是这个 黑洞 是我定义的术语,它是用来表示 内存吞噬 的一种现象,何为 内存吞噬 ,我们来看一张图。 从上面的 卦象图 来看,GCHeap 的 Allocated=852M 和 Committed=16.6G ,它们的差值就是 分配缓冲区=16G ,缓冲区的好处就是用空间换时间,弊端就是会实实在在的侵占内

    2024年02月16日
    浏览(17)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包