在VS15上远程调试Mono应用程序:原来还有这么舒服的姿势!

作者:V君 发布于:2018-10-27 22:48 Saturday 分类:折腾手记

小试一把确认可行之后就来写博文了,稍后再扯,先TLDR:

关键字「mono remote debug」喂狗,吐出「MonoRemoteDebugger」插件。

顺着介绍导航到其GitHub仓库看用法

0)目标机器需要先安装Mono的软件包,这次用的是「mono-devel」
1)下载预编译版本zip到目标机器,解包执行,进入等待状态。
2)在VS里装好插件,新建一个控制台项目,
  点击菜单「
MonoRemoteDebugger -> Debug with Mono (remote)
  在弹出的对话框输入目标机器IP,点击连接按钮。
3)当前应用程序会自动推送到目标机器并以调试模式启动,
  如果在主线程设置断点,将会在断点处停下来,此时可以查看变量值。

需要注意的是Mono调试器并没有原生的那么强大,做不到编辑并继续的体验。
受到远程调试器完善程度的影响,目前还不支持用户线程断点。

不过没关系能打断点看变量值已经很奢侈啦!

进入闲话时间

还记得之前为了调试树莓派GPIO所做的C/S远程控制接口吗?
最近忽然想玩PWM,想试着用它来控制LED灯的亮度。
首先想到的是树莓派自带的Remote gpio功能,然而资料并不多,只能找到py的,没有C#的。
之后换了个想法,如果能直接在上面跑调试那该多好。
虽然知道可以在上面直接安装MonoDevelop来调试,但这货太过于臃肿。
又试着去咕狗看看,结果就找到这货啦!


标签: 软件开发 树莓派 C# 嵌入式 调试技术

评论(0) 引用(0) 浏览(49)

搭建自己的NuGet托管服务器,并通过符号源服务器提供带源码的调试体验

作者:V君 发布于:2018-9-19 19:43 Wednesday 分类:挖坑经验

尽管花了不少时间但都是些坑或者自己没注意,这次不想扯,直接TLDR:


使用命令行把项目打包并推送到服务器 (参考官方文档)

1) 下载最新版NuGet.exe,

2) 为项目编写nuspec文件,可以通过spec参数创建一个模板

3) 分别使用pack命令打包库pack -symbol也生成符号包

4) 使用push命令将这俩分别推送到对应服务器

+) 如果想连同PDB文件一起打包(可以堆栈跟踪里获得源代码位置),可以添加下配置到nuspec根

  <files>
    <file src="bin\$configuration$\$id$.pdb" target="lib\netxxx\" />
  </files>

 这样做有个副作用会让符号包生成时产生警告PDB文件重复

 还有一个副作用会让符号源失效,在DLL旁边PDB似乎挡住了前往符号源服务器的去路,

 导致F11进不去,你得在启动调试之前自己把输出目录的PDB删除

 目前的做法是写成生成事件,仅匹配Debug生成时删除指定的PDB文件


搭建NuGet服务器 (参考自官方文档)

1) 新建空白Web项目,引入NuGet包[NuGet.Server]

2) 修改web.config配置ApiKey或干脆禁用验证

3) 部署到服务器


搭建符号服务器 (参考X.D.的博客文章)

1) 创建空白MVC项目,引入NuGet包[SymbolSource.Server.Basic]

2) 在服务器上安装Windows Kits Debuggers,下载SDK安装器进行可选安装

3) 部署到服务器,配置好web.config指向上者安装路径的srcsrv

4) 如果用了主机头绑定和HOSTS,在服务器也需要配置指向自己的HOSTS

x) 这货好像也能当NuGet包托管服务器?(但貌似不能设置ApiKey验证


在VS使用自己部署的NuGet包服务器

1) 在菜单工具-选项打开选项对话框

2) 在左边选择NuGet包管理器-程序包源,添加服务器地址到列表,确定

3) 在包管理器检索时不要忘记切换到自己的服务器,或简单选择全部


在VS使用调试符号 (参考符号源官网文档)

1) 在菜单工具-选项打开选项对话框

2) 在左边选择调试-符号,添加服务器地址到列表

3) 接着在左边找到兄弟节点常规对里面的选项做一些改动,见参考文档

4) 在调试时对着提供了符号包的NuGet程序集调用按下F11, VS会自动找到源代码并进入调试


扩充话题


在程序集里嵌入Git提交哈希,可以使用[MSbuildGitHash]这个包来轻松完成

但这货有个缺点,如果机器上没安装Git或者当前项目不是Git托管,就会编译失败

需要自己指定MSBuild条件来绕过.


标签: 软件开发 源码管理 调试技术 .NET

评论(0) 引用(0) 浏览(102)

使用Windbg+sos+sosex从内存转储详细分析对象引用,排查.NET服务应用内存暴增

作者:V君 发布于:2018-8-22 12:37 Wednesday 分类:填坑经验

TL;DR

1) 准备:先载入转储

 如果缺少dll, 去 https://sos.debugging.wellisolutions.de/ 找

 下来放windbg旁边,然后重新载入.

2) 初始化:载入sos和sosex [.loadby sos mscorwks],[.load sosex],首次要执行[!bhi]

3) 对象统计:用sos的[!dumpheap -stat]或者sosex的[!sosex.mfrag -stat]获取结果

4) 枚举对象:用sos的[!dumpheap -type <上结果类名>]就能刷出

  sosex的[mfrag -mt:类名]如果能用就可以直接点击链接, 这次不知道为啥不工作.

5) 查找引用:用sosex的[!refs <上结果地址>]

  顺着地址链接一路跟踪就能定位内存占用的代码位置.

 

 

必须扯:

阅读全文>>

标签: 软件开发 C# 调试技术 windbg 软件故障诊断 sosex

评论(0) 引用(0) 浏览(105)

活久见:表达式树编译执行引发VerificationException—操作可能会破坏运行时稳定性

作者:V君 发布于:2018-2-7 0:04 Wednesday 分类:挖坑经验

TL;DR:

当在使用表达式树编译成员绑定表达式,且存在隐式值类型装箱,

将表达式树编译成的委托执行起来的时候将会引发异常VerificationException

并提示消息“操作可能会破坏运行时稳定性

解决方法为显式装箱之后再绑定,可能是表达式树在编译成IL时没有对其进行必要的校验。

至于是不是性能考虑就不晓得了。从结果上来看,似乎却在运行时(亦或者JIT时)有检查。


听我扯扯:

在项目中需要比较两个同类型对象实例,且将差异收集起来。

于是咱首先就想到:不要一遍遍写繁琐的判断!

而是使用动态行为——堆IL、拼代码动态编译或表达式树编译。

咱选择后者,比起堆IL和拼代码还是表达式树写起来更舒服。


就算使用动态行为,基础的动作还是由简单的逻辑语句组成。

首先要遍历要diff的类的全部属性,然后将两个实例对应的属性值读出来比较,

若值相等则忽略,若值差异则连同属性名和两个差异的值收集起来。


思路想清楚了就开始吧。


定义一个有3个属性的类,分别存放属性名,和两个值,作为差异条目模型。

命名DiffEntry属性名是字符串,另外两个是object。


接着定义一个静态泛型类,静态构造里面构建每个属性的比较表达式树并将它们编译成委托,

公开静态方法Diff,返回DiffEntry的数组,调用编译好的委托。

命名ObjDiffCollector,存在引发装箱异常问题。

在gist描述为修订2,因为最初使用数组存放编译出来的委托,发生异常之后,

为了调查异常引发原因缩小范围,改为字典,键是属性名,值是委托,仅用在调试查看。


将问题缩小到值类型在DiffEntity的构造初始化成员绑定之后,

          .↑字符串类型没有问题

开始一小会儿的懵逼,放狗出去并没有找到什么卵线索。


这段可以忽略

先贴上异常名称,咕狗很贴心地提示了“operation could destabilize the runtime”,

接着出来的只有一个爆栈帖子,提到使用一个第三方数据访问层引发这样的错误。

打住吧,换成中文消息搜一下看看。

和预料的一样然并卵,被一篇转载到成为互联网垃圾程度的文章刷屏。

文章清一色的提到使用redgate的性能测量库所引发。

到这里线索断了。时间也不早,还要赴约,就把问题撂下跑了。

离开电脑面前不久之后,又玩了一次当局者迷play。

在外头晃悠时忽然灵光一现想到可能是隐式装箱导致,最终证实这个想法。


THE MEAT AND POTATOES 圈重点啦

可能堆IL和表达式编译一样,没有经过太完整的代码转换过程,隐式行为需要显式表达。

这时候需要将绑定的表达式加一层,转换成object,也就是显式装箱。

最终得出可用的ObjDiffCollector


回过头来想一想,发现CLR报这个错误也不无道理。

试想一下:一个非引用类型的结构体被装箱的情形,如果再复杂一点如果和原生代码扯上关系。

可能会导致意外的值复制行为,从而影响到整个应用程序的稳定性。

想当年,玩DllImport时,一不小心就内存损坏或者堆栈不平衡……


到此为止啦,收工!


接下来该考虑如何一步到位了,或许可以在一个表达式里面作完所有属性的比较和收集差异。

让代码的逼格显得更高。 乂目

标签: 软件开发 C# 调试技术 JIT LINQ 运行时错误

评论(0) 引用(0) 浏览(245)

排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数

作者:V君 发布于:2017-6-9 17:01 Friday 分类:填坑经验

WEB应用程序出现响应很慢甚至卡死的现象,

Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)


于是锅放到我这里辣.


DebugDiag得出堆栈已经显示具体代码位置了, 

想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.

 

参考其 sosex 的 readme.txt MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈

要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )


搞起! .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程

然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值

这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.

 

标签: 软件开发 ASP.NET 调试技术 windbg

评论(0) 引用(0) 浏览(596)

Powered by emlog 去你妹的备案 sitemap