WebActivatorEx重复执行?不!那是作为使用者的我们傻逼!!

作者:V君 发布于:2018-6-15 22:42 Friday 分类:挖坑经验

TL;DR:

如果在发布新版本后出现疑似WebActivatorEx启动入口被执行多次的情况

首先检查bin里面是否有上个版本残留的DLL,干掉它们就解决了,然后把锅甩给运维

 

那么,开始我的故事。


~前奏~


由于首次在正式项目引入git源代码管理体系,仓库结构设计的相当散乱。

这不赶上重组git仓库,重新建立了解决方案,命名空间和项目名称也重新规划了。



好不容易发布一个新版本到测试环境,运行起来出现致命错误的黄页。

连最开始的初始化都没完成,错误处理也措手不及,好久不见的黄页就这样呈现出来。


~扯一扯~


由于不喜欢Log4Net这种只能用配置文件的充满Java味道的东西。

现在项目中的日志组件是由我自己实现的,有以下特性:

  • 由写入时间决定文件名
  • 6个级别,外加可选启用的虚拟级别“ALL”将其他级别内容凑一起输出
  • 按指定大小分文件
  • 多次启停可续写
  • 自动删除指定天数的旧文件

写入方式是基于线程安全的FileStream共享只读打开,方便边写边看。

内容格式是三行一空行的条目:

  • 第一行写时间、级别、线程信息(如果有写程序集,也能快速发现这次的问题。之后补上吧)
  • 第二行写摘要,由开使用者定义的简短摘要
  • 第三行写详情的JSON,有日志位置堆栈,可以加入任意对象作为附加信息

在日志组件初始化之后,我通常会打一句“Logger Init”在日志中体现应用程序启动。

我们有为此专门做了个小工具来分析日志,用上了Chris NielsenJSON可视化界面实现。


~诊断~


打住,话题收回来,黄页的错误信息是“文件被占用”,堆栈显示正在打“Logger Init”时…

一开始的时候很有自信,以为自己写的实现没问题,可能被文件共享出来占用了。

用Procexp查文件句柄,一个都没查出… 

但作为应用程序启动的体现“Logger Init”却被打进日志文件里…

老大的意思是想让我先把多节点负载均衡砍掉,以单节点跑起来,降低复杂度再诊断。

当时没辙只好听话照办喽,然并卯。

还是掏出诊断大杀器ProcMon看看“是谁动了我的奶酪”,看到结果时开始觉得自信不足了:

——真的是ASP.NET程序池进程访问的文件,而且是同一条原生线程访问了两次。

——第一次成功打开,第二次打开失败,最后还把文件关闭了——由CLR,程序都崩溃了嘛!

难道是自己的实现有问题,多线程竞态现象?

.NET的托管线程可能会复用原生线程,出现TID一样的情况也不能排除多线程。

在初始化的地方加了锁,然而问题依旧存在。其实并不是我的代码写的不严谨,这是后话。


咋办?


让文件打开的共享模式可读可写吧,想到了这样高风险的激进尝试。

然而——还是失败了,但仔细观察发现ProcMon监视条目详情有蹊跷:

第一次打开文件的共享模式是只读,第二次才是符合激进尝试的可读可写。

两次打开文件的原生堆栈有差异,很可惜看不到托管堆栈,如果能看到程序集就能解决问题了。

远程调试吧。没办法的办法了,在日志初始化的地方打个断点看看会不会两次命中。

调试结果令人十分失望,只命中了一次,打开失败的第二次。天知道第一次在哪儿打开?

这时猫同事建议我把“Logger Init”改一下,看看有没有打出来。这才恍然大悟。

我拒绝了建议,且断言上个版本残留程序集,去服务器bin看看,断言成立!

抓住运维的肩膀使劲晃,“你让我浪费了两天的时间排查” 乂目


~结语~


甩完锅之后还是要总结一下教训的,发布版本应该将之前的文件干掉,再把新的包部署上去。

标签: 软件开发 C# ASP.NET 软件故障诊断

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

Winform小技巧:让窗体直接使用exe图标(PE资源),避免重复嵌入图标资源

作者:V君 发布于:2018-3-20 17:52 Tuesday 分类:挖坑经验

TL;DR

用CodeProject上的帖子的实现, 传入主程序路径, 检查图标个数, 将首个图标给需要的主窗体.


扯一扯:

有点.net开发经验的人都应该知道: Winform窗口图标和exe文件图标不是同一个东西,

假如有需要使用同一个图标的情况, 那将会保存两份数据, 令有强迫症的人(比如我)抓狂.

之前有折腾过Windows图标相关的操作, 这次也轻松提取主程序图标然后应用到主窗体上.


PS.这种方式可以支持多尺寸图标, 简单调用ExtractIcon的方式不支持多尺寸.

标签: 软件开发 C# Interop Winform

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

活久见:表达式树编译执行引发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) 浏览(138)

[成功]又一次自己编译Mono,这次是在Windows上,玩Bundle

作者:V君 发布于:2017-10-30 21:07 Monday 分类:折腾手记

目标 -- 将 .net 应用程序用只用一个 exe 承载, 并极大缩减体积, 且能保证工作正常.


(这次不是针对性的解决问题, 不TL;DR (´∀((☆ミつ 


篇幅较长, 进来看

阅读全文>>

标签: 软件开发 C# 命令行 mono 软件故障诊断

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

批量下载在漫画的通用解决方法,包括脚本生成内容

作者:V君 发布于:2017-10-25 13:43 Wednesday 分类:折腾手记

TLDR:

由于太过简单(也就百来行代码),写得还有点丑,就不传到SVN上了 (´∀((☆ミつ

流程大概如下:
  1. CsQuery解析HTML
  2. jurassic解析Javascript
  3. Newtonsoft解析Json对象
  4. PLINQ多线程下载图片文件

进来听我扯扯

阅读全文>>

标签: 软件开发 javascript C# Chrome 爬虫 HTML Web技术

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

Powered by emlog 去你妹的备案 sitemap