重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]( 二 )

2023-10-19 生活百科

详细信息如下：https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy
进行开启：

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
然后重启，再来点击clash3进行崩溃一下。

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
可以看到这里就有了。
这里我们先转储文件符号一下:
dotnet-symbol /tmp/coredump.9784-o /dumps/symbols/ --host-only然后进去一下：
lldb --core /tmp/coredump.9784这个时候要加载一下dotnet 符号。
setsymbolserver -directory /dumps/symbols/然后加载转储文件符号:
loadsymbols这样就搞定了。
clrsthread 查看一下线程的情况:

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
这里可以看到里面有个异常是15号线程。
切到15号线程：
setthread 15:

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
然后查看一下clrstack(调用栈信息):

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
这个似乎没有告诉我们很多很有用的信息，只能告诉我们线程异常了，当然也告诉我们具体的行，可以去看下去源代码看下什么类型异常，但是有跟好用的pe 。
用pe查看下：
pe-- Displays and formats fields of any object derived from the Exception class at the specified address.

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
【重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]】这样就定位到具体的崩溃文件了。
知道了崩溃是因为HttpWebRequest，希望的是能查到到底是哪个访问url造成了崩溃。
下面这个图，证明可调用了HttpWebRequest引发的:

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
使用dumpheap：dumpheap -stat -type System.Net.HttpWebRequest 查看httpwebrequest 调用栈:

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
查看栈地址:

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
然后是根据地址查看对象：dumpobj 00007fe0c4442f28

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
这个webrequest 里面有一个是system.url 我们写程序的知道这是访问地址。
然后继续查这个对象，上面那个value 就是地址哈。
00007fe0c4437cf8然后可以看到url 地址：

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
第一个就是了，为什么确认第一个就是，看名字。

重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]

文章插图
这样就查到了。
先到这里吧，介绍这个lldb 是为了查看非托管栈的，如果查看托管的一般使用dotnet-dump 就好了。
而且一般是用来分析cpu 和内存高的地方，一般服务端错误会有日志的。
结继续后面演示cpu 和内存高的例子，这个对服务端更有实用性。

推荐阅读

上一篇：谣言检测《Rumor Detection with Self-supervised Learning on Texts and Social Graph》

下一篇：HPL Study 2