.NET关于API 句柄泄漏分析

 更新时间:2021-09-22 21:45:27   作者:佚名   我要评论(0)

目录一:背景1. 讲故事2. 什么是句柄二: windbg 分析1. 看问题表象2. 查看句柄表3. 从托管堆找 OverlappedData 的徒孙辈4. 寻找最终答案三:

一:背景

1. 讲故事

上上周有位朋友找到我,说他的程序CPU和句柄都在不断的增长,无回头趋势,查了好些天也没什么进展,特加wx寻求帮助,截图如下:


看的出来这位朋友也是非常郁闷,出问题还出两个,气人哈,关于 cpu 爆高的问题我准备单独用一篇文章去侦读,这篇就先聊聊 句柄泄漏 的问题,毕竟写了20多篇,也是第一次聊到 handle 泄露,有点意思哈。

2. 什么是句柄

我个人理解的句柄:就是在托管层持有了一个对非托管层资源的引用,有了这个引用,我们就可以强制回收非托管资源,那什么是非托管资源? 我个人的理解是 gc 管不到的地方都是 非托管资源

通常包含这种句柄的类有: FileStream, Socket 等,如果大家有这个前置基础,接下来就可以用 windbg 去分析啦!

二: windbg 分析

1. 看问题表象

朋友从 任务管理器 中看到 handle =8770,那就说明程序中有 8770 个对非托管资源持有句柄,那怎么去看呢? 在说这个之前,大家有没有遇到这种现象,就是不管程序怎么泄漏,只要我们退出exe,那么所有的资源都会被神奇的 释放, 不管是托管资源还是非托管资源,这样说相信有很有朋友好奇这是怎么实现的??? 大家可以先想 10s。

揭晓答案啦! 简单的说, CLR 在内部维护了一张句柄表,当程序关闭时,CLR会强制释放句柄表中的所有句柄,那问题就简单了,既然 CLR 能触达,我相信通过 windbg 也能做到,对,就是通过 !gchandles 命令。

2. 查看句柄表

这里提醒一下,!gchandles 的作用域是 AppDomain,而不是 Process,接下来看一下命令输出:

0:000> !gchandles -stat
Statistics:
              MT    Count    TotalSize Class Name
...
00007ffccc1d2360        3       262280 System.Byte[]
00007ffccc116610       72       313224 System.Object[]
00007ffccc3814a0     8246       593712 System.Threading.OverlappedData
Total 10738 objects

Handles:
    Strong Handles:       312
    Pinned Handles:       18
    Async Pinned Handles: 8246
    Ref Count Handles:    1
    Weak Long Handles:    2080
    Weak Short Handles:   59
    Dependent Handles:    22

从输出看,有一组数据特别刺眼,那就是: Async Pinned Handles = 8246 [System.Threading.OverlappedData],这是什么意思呢? 从英文名就能看出这是一个和 异步IO 相关的句柄,有些朋友应该知道,在异步IO的过程中,会有一个 byte[] 被 pinned 住,同时还有一个异步IO的上下文对象 OverlappedData

接下来的一个问题是:既然是异步IO,那它的 handle 是什么类型,如前面所说是 FileStream 还是 Socket ? 要想找出答案,就需要深挖 OverlappedData 对象,相关的命令是: !dumpheap -mt xxx & !do ... ,参考如下:

0:000> !DumpHeap /d -mt 00007ffccc3814a0
         Address               MT     Size
000001aa2acb39c8 00007ffccc3814a0       72     
000001aa2acb3fd8 00007ffccc3814a0       72     
000001aa2ad323d0 00007ffccc3814a0       72     
...
0:000> !do 000001aa2acb39c8
Name:        System.Threading.OverlappedData
MethodTable: 00007ffccc3814a0
EEClass:     00007ffccc37ca18
Size:        72(0x48) bytes
File:        C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffccc21f508  40006b2        8  System.IAsyncResult  0 instance 0000000000000000 _asyncResult
00007ffccc110ae8  40006b3       10        System.Object  0 instance 000001aa2acb4020 _callback
00007ffccc381150  40006b4       18 ...eading.Overlapped  0 instance 000001aa2acb3980 _overlapped
00007ffccc110ae8  40006b5       20        System.Object  0 instance 000001aa2acb9fe8 _userObject
00007ffccc11f130  40006b6       28                  PTR  0 instance 000001aa2a9bd830 _pNativeOverlapped
00007ffccc11ecc0  40006b7       30        System.IntPtr  1 instance 0000000000000000 _eventHandle
0:000> !DumpObj /d 000001aa2acb3980
Name:        System.Threading.ThreadPoolBoundHandleOverlapped
MethodTable: 00007ffccc3812a0
EEClass:     00007ffccc37c9a0
Size:        72(0x48) bytes
File:        C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffccc3814a0  40006ba        8 ...ng.OverlappedData  0 instance 000001aa2acb39c8 _overlappedData
00007ffccc34fcd0  40006a4       10 ...ompletionCallback  0 instance 000001aa2acb3920 _userCallback
00007ffccc110ae8  40006a5       18        System.Object  0 instance 000001aa2acb38c8 _userState
00007ffccc380120  40006a6       20 ...locatedOverlapped  0 instance 000001aa2acb3960 _preAllocated
00007ffccc11f130  40006a7       30                  PTR  0 instance 000001aa2a9bd830 _nativeOverlapped
00007ffccc380eb8  40006a8       28 ...adPoolBoundHandle  0 instance 000001aa2acb3900 _boundHandle
00007ffccc1171c8  40006a9       38       System.Boolean  1 instance                0 _completed
00007ffccc34fcd0  40006a3      458 ...ompletionCallback  0   static 000001aa2acb4020 s_completionCallback
0:000> !DumpObj /d 000001aa2acb3900
Name:        System.Threading.ThreadPoolBoundHandle
MethodTable: 00007ffccc380eb8
EEClass:     00007ffccc37c870
Size:        32(0x20) bytes
File:        C:\xxx\xxx\vms_210819\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffccc1d76b0  40006a1        8 ...rvices.SafeHandle  0 instance 000001aa2acb1d30 _handle
00007ffccc1171c8  40006a2       10       System.Boolean  1 instance                0 _isDisposed

0:000> !DumpObj /d 000001aa2acb1d30
Name:        Microsoft.Win32.SafeHandles.SafeFileHandle
MethodTable: 00007ffccc3807c8
EEClass:     00007ffccc37c548
Size:        48(0x30) bytes
File:        C:\xxx\xxx\xxx\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffccc11ecc0  4000bb4        8        System.IntPtr  1 instance 0000000000000428 handle
00007ffccc11b1e8  4000bb5       10         System.Int32  1 instance                4 _state
00007ffccc1171c8  4000bb6       14       System.Boolean  1 instance                1 _ownsHandle
00007ffccc1171c8  4000bb7       15       System.Boolean  1 instance                1 _fullyInitialized
00007ffccc2f1ae0  4001c3d       20 ...Private.CoreLib]]  1 instance 000001aa2acb1d50 _isAsync
00007ffccc380eb8  4001c3e       18 ...adPoolBoundHandle  0 instance 0000000000000000 <ThreadPoolBinding>k__BackingField

上面倒数第五行的 0000000000000428 就是具体的 handle 值,接下来就可以用 !handle 命令查看其值的具体信息。

0:000> !handle 0000000000000428 7
Handle 428
  Type         	File
  Attributes   	0
  GrantedAccess	0x100081:
         Synch
         Read/List,ReadAttr
  HandleCount  	2
  PointerCount 	65489

Type:File 可以看出,原来这 8000 多都是文件句柄哈。。。

写到这里貌似就到了死胡同了😪😪😪,虽然挖了一些信息,但这些信息还不足以让我找到问题根源,从引用链上来说,gchandles 中的这些对象是处于引用链的顶端,换句话说,我需要找到这条引用链下游的一些数据对象,一个好的入口点就是到 heap 中去挖。

3. 从托管堆找 OverlappedData 的徒孙辈

首先我们用 !dumpheap -stat 查看下托管堆。

0:000> !dumpheap -stat
Statistics:
              MT    Count    TotalSize Class Name
...

00007ffccc3c5e18   939360     52604160 System.Collections.Generic.SortedSet`1+Node[[System.Collections.Generic.KeyValuePair`2[[System.String, System.Private.CoreLib],[System.String, System.Private.CoreLib]], System.Private.CoreLib]]
00007ffccc1d2360    16492     69081162 System.Byte[]
000001aa2a99af00    10365     76689384      Free
00007ffccc1d1e18  1904987    116290870 System.String

既然是找引用链下游,那就从基础类型 System.String 或者 System.Byte[] 入手,这里我就选择前者,写了一个对 mt 下所有 address 进行分组统计的脚本,毕竟人肉是不可能的,从脚本的输出中我抽了几个 address 查看 !gcroot,大概都是类似这样的内容。

0:000> !gcroot 000001aa47a0c030
HandleTable:
    000001AA4469C090 (async pinned handle)
    -> 000001AA491EB908 System.Threading.OverlappedData
    -> 000001AA491EB8C0 System.Threading.ThreadPoolBoundHandleOverlapped
    -> 000001AA491EB860 System.Threading.IOCompletionCallback
    -> 000001AA491EAF30 System.IO.FileSystemWatcher
    -> 000001AA491EB458 System.IO.FileSystemEventHandler
    ...
    -> 000001AA47A0C030 System.String

0:000> !gcroot 000001aa2d3ea480
HandleTable:
    000001AA28FE9930 (async pinned handle)
    -> 000001AA2DD68220 System.Threading.OverlappedData
    -> 000001AA2DD681D8 System.Threading.ThreadPoolBoundHandleOverlapped
    -> 000001AA2DD68178 System.Threading.IOCompletionCallback
    -> 000001AA2DD67848 System.IO.FileSystemWatcher
    ...
    -> 000001AA2D3EA480 System.String    

从整个引用链来看,里面都有一个 System.IO.FileSystemWatcher ,这和前面分析的 handle= File 是一致的,然后就是导出这些 string ,发现大部分都是和 appSettings 相关,如下所示:

string: appSettings:RabbitMQLogQueue
string: appSettings:MedicalMediaServerIP
string: appSettings:UseHttps
...

然后用 !strings 命令进行了模糊匹配,发现这样的string 高达 61w 。。。

到这里基本就能断定:appsettings 被 watch 了,但 watch 的方式有问题。。。

4. 寻找最终答案

将调查结果给了朋友之后,让朋友着重观察下对 appsetting 进行 watch 的方式是否有问题? 几个小时后,朋友终于找到了。


大概意思是说:本身已经通过设置 reloadOnChange=true 对 appsetings 进行了监控,但写码的人对这一块不熟悉,又通过每10s一次轮询对appsettings进行数据感知,问题就出现在这里。。。

三:总结

其实本次事故的主要原因还是在于对如何实时感知 appsettings 中最新数据的玩法不熟悉,一边用了 .netcore 自带的 reloadOnChange 监控,一边还用轮询的方式进行数据感知,所以说基础还是很重要的,不要想当然的去写! 😁😁😁

到此这篇关于.NET关于API 句柄泄漏分析的文章就介绍到这了,更多相关.NET API 句柄泄漏内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
  • .NET资源泄露与处理方案知识点分享

相关文章

  • .NET关于API 句柄泄漏分析

    .NET关于API 句柄泄漏分析

    目录一:背景1. 讲故事2. 什么是句柄二: windbg 分析1. 看问题表象2. 查看句柄表3. 从托管堆找 OverlappedData 的徒孙辈4. 寻找最终答案三:
    2021-09-22
  • 运用.net core中实例讲解RabbitMQ

    运用.net core中实例讲解RabbitMQ

    目录一、RabbitMQ简介(1) AMQP协议(2)AMQP专业术语(3)RabbitMQ整体架构二、安装RabbitMQ三、RabbitMQ六种队列模式在.NetCore中使用(1)简单队
    2021-09-22
  • 运用.NetCore实例讲解RabbitMQ死信队列,延时队列

    运用.NetCore实例讲解RabbitMQ死信队列,延时队列

    目录一、死信队列二、延时队列三、延时消息设置不同过期时间四、延时消息用延时插件的方式实现一、死信队列 描述:Q1队列绑定了x-dead-lett
    2021-09-22
  • Quartz.NET的具体使用

    Quartz.NET的具体使用

    目录一、什么是Quartz.NET?二、Quartz.NET可以做什么?三、ASP.NET Core如何使用Quartz.NET?四、Quartz的cron表达式一、什么是Quartz.NET?
    2021-09-22
  • asp.net core3.1cookie和jwt混合认证授权实现多种身份验证方案

    asp.net core3.1cookie和jwt混合认证授权实现多种身份验证方案

    目录认证授权 身份认证 授权 默认授权选择授权总结 开发了一个公司内部系统,使用asp.net core 3.1。在开发用户认证授权使用的是简单的c
    2021-09-22
  • 详解.NET数据库连接池

    详解.NET数据库连接池

    目录前置知识背景1. .NET数据库连接池的背景2. .NET 数据库连接池的表现3. .NET是如何形成数据库连接池的&#63;4. 连接池中的连接什么时候被移
    2021-09-22
  • .Net Core 之AutoFac的使用

    .Net Core 之AutoFac的使用

    目录Autofac介绍组件的三种注册方式生命周期AutoFac 在asp .net core中的使用本文不介绍IoC和DI的概念,如果你对Ioc之前没有了解的话,建议先
    2021-09-22
  • Asp.net Core 如何设置黑白名单(路由限制)

    Asp.net Core 如何设置黑白名单(路由限制)

    在原有的AspnetMvc中我们会使用到路由访问限制,在AppStart/RouteConfig.cs中写上如下: routes.IgnoreRoute("{resource}.axd/{*pathInfo}
    2021-09-22
  • C#中efcore-ShardingCore呈现“完美”分表

    C#中efcore-ShardingCore呈现“完美”分表

    目录efcore支持情况 数据库支持情况如何开始使用 自定义分表键,自定义分表规则 默认路由 动态添加分表信息 支持select,join,group by等
    2021-09-22
  • .NET Core对象池的应用:编程篇

    .NET Core对象池的应用:编程篇

    目录一、对象的借与还二、依赖注入三、池化对象策略四、对象池的大小五、对象的释放借助于有效的自动化垃圾回收机制,.NET让开发人员不在关心
    2021-09-22

最新评论