在 lldb 中打开核心转储文件之前,请按照以下必需步骤设置符号路径,下载符号,并在打开 lldb 时自动加载 SOS :
安装 dotnet 符号工具:
dotnet tool install -g dotnet-symbol
下载目标转储文件的符号:
dotnet-symbol <path_of_dump_file>
安装 SOS:
安装 dotnet-sos 全局工具:
dotnet tool install -g dotnet-sos
安装 SOS:
dotnet-sos install
最后成功的样子:
文章插图
使用createdump:
Createdump 会与每个 .NET Core 运行时一起自动安装 。
如 创建的ump 配置策略 文档中所述,可以设置具有环境变量的配置选项 。这些将作为参数传递给创建的ump 命令 。下面是支持的环境变量:
COMPlus_DbgEnableMiniDump:如果设置为 1,则在终止时启用自动核心转储生成 。默认值为 0。COMPlus_DbgMiniDumpType:这是将要创建的微型转储文件的类型 。此值的默认值为 2 (或枚举类型 MiniDumpWithPrivateReadWriteMemory)。这意味着生成的转储文件将包括 GC 堆以及捕获进程中所有现有线程的堆栈跟踪所需的信息 。COMPlus_DbgMiniDumpName:如果设置,请用作模板来创建转储文件路径和文件名 。可以使用参数将 PID 放入名称中 %d。默认模板为 /tmp/coredump.%d. 通过使用此环境变量,可以配置输出目录 。COMPlus_CreateDumpDiagnostics:如果设置为 1,则启用创建的ump 工具诊断消息 (TRACE 宏)。如果 createdump 不能按预期工作并且不生成内存转储文件,则此设置可能很有用 。
详细信息如下:https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy
进行开启:
文章插图
然后重启,再来点击clash3进行崩溃一下 。
文章插图
可以看到这里就有了 。
这里我们先转储文件符号一下:
dotnet-symbol /tmp/coredump.9784-o /dumps/symbols/ --host-only
然后进去一下:lldb --core /tmp/coredump.9784
这个时候要加载一下dotnet 符号 。setsymbolserver -directory /dumps/symbols/
然后加载转储文件符号:loadsymbols
这样就搞定了 。clrsthread 查看一下线程的情况:
文章插图
这里可以看到里面有个异常是15号线程 。
切到15号线程:
setthread 15:
文章插图
然后查看一下clrstack(调用栈信息):
文章插图
这个似乎没有告诉我们很多很有用的信息,只能告诉我们线程异常了,当然也告诉我们具体的行,可以去看下去源代码看下什么类型异常,但是有跟好用的pe 。
用pe查看下:
【重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]】
pe-- Displays and formats fields of any object derived from the Exception class at the specified address.
文章插图
这样就定位到具体的崩溃文件了 。
知道了崩溃是因为HttpWebRequest,希望的是能查到到底是哪个访问url造成了崩溃 。
下面这个图,证明可调用了HttpWebRequest引发的:
文章插图
使用dumpheap:dumpheap -stat -type System.Net.HttpWebRequest 查看httpwebrequest 调用栈:
经验总结扩展阅读
- .NET 7 中 LINQ 的疯狂性能提升
- 两种 .Net Core 3.0 对 MongoDB 的多条件查询操作
- 螃蟹凉了可以重新加热吗
- 螃蟹断掉的腿,还能重新长出来吗?
- .NET性能优化-复用StringBuilder
- .net 温故知新:【8】.NET 中的配置从xml转向json
- 哪些星座男生视妻如命
- 如何在.NET程序崩溃时自动创建Dump?
- .NET Conf 2022 &ndash; 11 月 8 日至 10 日
- .NET 零开销抽象指南