C# on Melchior on CLR

Molecule to atoms

Thu, 08 Aug 2019 22:57:35 +0000

同学发过来一道有意思的题

For a given chemical formula represented by a string, count the number of atoms of each element contained in the molecule and return an object (associative array in PHP, Dictionary<string, int> in C#, Map<String,Integer> in Java).

For example:

var water = 'H2O';
parseMolecule(water); // return {H: 2, O: 1}

var magnesiumHydroxide = 'Mg(OH)2';
parseMolecule(magnesiumHydroxide); // return {Mg: 1, O: 2, H: 2}

var fremySalt = 'K4[ON(SO3)2]2';
parseMolecule(fremySalt); // return {K: 4, O: 14, N: 2, S: 4}

As you can see, some formulas have brackets in them. The index outside the brackets tells you that you have to multiply count of each atom inside the bracket on this index. For example, in Fe(NO3)2 you have one iron atom, two nitrogen atoms and six oxygen atoms.

Note that brackets may be round, square or curly and can also be nested. Index after the braces is optional.

一句话描述:统计化学式中出现各个原子的个数.

不含括号的化学式很好解析,带上括号只要依次处理括号里的部分,乘以括号后的倍数就完成了.而括号里的部分又可以是一个完整的化学式.完美的分治.

以K4[ON(SO3)2]2为例.首先解析K4,接着解析[ON(SO3)2]2,碰到括号解析字串ON(SO3)2,对应个数乘2再合并即可.ON(SO3)2也一样,解析出O,N后继续解析括号里的(SO3)2即可.

解析字符串一般可以转化成解析上下文无关文法,答案就在生成的AST中.

所有的括号{},[]替换为()后均不影响结果.这里就偷个懒

生成式:

Number: [1-9][0-9]*
Atom:[A-Z][a-z]*
Term: Atom Number
Molscule: TermTerm*
        | Term*(Molscule)Number?Term*

原子以大写字母开头,后跟任意个小写字母
化学式的一项是一个原子后跟一个分子.
分子式可以由至少一个项构成
分子式可以由任意项中间插入左括号(,另一个分子式右括号)和一个可选的数字构成.

由生成式就可以动手写解析器啦.首先对每一个可能的分支都写出一个完整的解析函数,在无法确定接下来是哪个分支的时候使用超前查看来实现分支预测.

 class Program
    {

        static void Main(string[] args)
        {
            Console.WriteLine("Please enter a chemical");
            Console.WriteLine("Default: K4(ON(SO3)2)2");

            string source = "K4(ON(SO3)2)2";
            var str = Console.ReadLine();
            str = string.IsNullOrWhiteSpace(str) ? source : str;
            var dict = Parse(str, 0, 1);
            dict.ToList().ForEach(p => Console.WriteLine($"{p.Key}:{p.Value}"));
            Console.WriteLine("Press any key to continue");
            Console.ReadLine();
        }

        static bool IsUpper(char c)
        {
            return c >= 'A' && c <= 'Z';
        }
        static bool IsLower(char c)
        {
            return c >= 'a' && c <= 'z';
        }
        static bool IsNumber(char c)
        {
            return c >= '0' && c <= '9';
        }

        static int GetNextElemIndex(string str, int start)
        {
            if (start >= str.Length) return -1;
            if (!IsUpper(str[start]))
            {
                return -1;
            }
            for (int i = start + 1; i < str.Length; i++)
            {
                if (!IsLower(str[i]) && !IsUpper(str[i])) return i - 1;
                if (IsLower(str[i]))
                {
                    continue;
                }
                if(IsUpper(str[i]))
                {
                    return i - 1;
                }
            }
             return str.Length - 1;
        }
        static int GetNextNumber(string str,int start)
        {
            if (start >= str.Length) return -1;
            if (!IsNumber(str[start])) return -1;
            for(int i=start;i<str.Length;i++)
            {
                if (!IsNumber(str[i]))
                    return i - 1;
            }
            if (IsNumber(str.Last())) return str.Length - 1;
            else return -1;
        }
        static int GetRightParin(string str,int start)
        {
            for(int i=start;i<str.Length;i++)
            {
                if (str[i] == ')') return i;
            }
            return -1;
        }
        static Dictionary<string, int> Parse(string str,int startIndex,int multiplex)
        {
            Dictionary<string, int> dict = new Dictionary<string, int>();
            while (true)
            {
                if (startIndex == str.Length)
                {
                    return dict;
                }
                var elem = GetNextElemIndex(str, startIndex);
                if (elem!=-1)
                {
                    // N个微元的情况,直接解析
                    var name = str.Substring(startIndex, elem - startIndex + 1);
                    int value = 1;
                    startIndex = elem + 1;
                    var num = GetNextNumber(str, startIndex);
                    if(num!=-1)
                    {
                        value = int.Parse(str.Substring(startIndex, num - startIndex + 1));
                        startIndex = num + 1;
                    }
                    if (!dict.ContainsKey(name)) dict[name] = 0;
                    dict[name] += value;
                }
                else if(str[startIndex]=='(')
                {
                    // 碰到括号,解析子化学式
                    var right = GetRightParin(str, startIndex + 1)+1;
                    var nextNum = GetNextNumber(str, right);
                    //子化学式的倍数
                    int mul = int.Parse(str.Substring(nextNum, nextNum - right + 1));
                    var recursion = Parse(str, startIndex + 1, mul);
                    startIndex = nextNum + 1;
                    //合并字典
                    recursion.Keys.ToList().ForEach(k => { if (!dict.ContainsKey(k)) dict[k] = 0; });
                    recursion.ToList().ForEach(p => dict[p.Key] += p.Value);
                    
                } else if(str[startIndex]==')')
                {
                    // 返回
                    return dict.ToDictionary(i => i.Key, i => i.Value * multiplex);
                } 
            }
        }
    }

获取程序的编译时间

Mon, 22 Oct 2018 23:16:44 +0000

日常新需求

新的需求又来了。这次是程序在编译后6个月拒绝启动。BETA性质的软件都有类似的需求。但大部分软件要么是启动时检查更新，要么是联网判断是否过期。对于我们现在做的这个小工具太小题大做了。根据编译时间判断过期的需求看似奇葩，也是有点道理的。

实现

遇事不决问SO，我们输入"C# get compile time"找到的第一个问题就是了。

方法有很多，大致分为这几类。

读取PE头部时间戳
添加Build Task将编译时间以资源嵌入程序集
读取文件创建时间

严格意义上说，文件创建时间与文件系统相关，依赖程序外部，碰到不保留创建时间的操作就只能干瞪眼了，所以排除掉。

而添加Build Task又需要程序读取资源，反序列化云云，比较麻烦。
因此主要关注1中的方法。

.NET的程序集都包含PE头部。先来一张图感受一下。

我们需要的字段在COFFHeader的TimeDateStamp处。

需要注意的一点是，图中的偏移量是相对PE头的，而在PE头部之前还有DOS头部。

再来看看StackOverflow上的答案，是不是比较直观呢？


// see https://stackoverflow.com/a/1601079
struct _IMAGE_FILE_HEADER
{
    public ushort Machine;
    public ushort NumberOfSections;
    public uint TimeDateStamp;
    public uint PointerToSymbolTable;
    public uint NumberOfSymbols;
    public ushort SizeOfOptionalHeader;
    public ushort Characteristics;
};

static DateTime GetBuildDateTime(Assembly assembly)
{
    var path = assembly.GetName().CodeBase;
    if (File.Exists(path))
    {
        var buffer = new byte[Math.Max(Marshal.SizeOf(typeof(_IMAGE_FILE_HEADER)), 4)];
        using (var fileStream = new FileStream(path, FileMode.Open,FileAccess.Read))
        {
            fileStream.Position = 0x3C;
            fileStream.Read(buffer, 0, 4);
            fileStream.Position = BitConverter.ToUInt32(buffer, 0); // COFF header offset
            fileStream.Read(buffer, 0, 4); // "PE\0\0"
            fileStream.Read(buffer, 0, buffer.Length);
        }
        var pinnedBuffer = GCHandle.Alloc(buffer, GCHandleType.Pinned);
        try
        {
            var coffHeader = (_IMAGE_FILE_HEADER)Marshal.PtrToStructure(pinnedBuffer.AddrOfPinnedObject(),typeof(_IMAGE_FILE_HEADER));
            return TimeZone.CurrentTimeZone.ToLocalTime(new DateTime(1970, 1, 1) + new TimeSpan(coffHeader.TimeDateStamp * TimeSpan.TicksPerSecond));
        }
        finally
        {
            pinnedBuffer.Free();
        }
    }
    return new DateTime();
}

从Ox3C位置读到PE头部的位置后Seek到该位置，读取内容后将其转换为自定义的_IMAGE_FILE_HEADER结构，读取TimeDateStamp即可。

直接运行的结果是1900/1/1 12:00:00，不对。原因是AssemblyName.CodeBase属性返回的并不是程序集所在路径，而是File scheme的URI file:\\\c:\MyDirectory\MyAssemlby.exe。使用AssemblyName后问题解决。从Ox3C位置读到PE头部的位置后Seek到该位置，读取内容后将其转换为自定义的_IMAGE_FILE_HEADER.TimeDateStamp，读取TimeDateStamp即可。 PE头部的TimeDateStamp字段是从unix epoll算起的，8102年的.NET中也有专门处理这里情况的DateTimeOffSet，而异常情况我们完全可以返回null。
修改后代码如下

static DateTimeOffset? GetBuildDateTime(this Assembly assembly)
{
    var path = assembly.Location;
    if (File.Exists(path))
    {
        var buffer = new byte[Math.Max(Marshal.SizeOf(typeof(_IMAGE_FILE_HEADER)), 4)];
        using (var fileStream = new FileStream(path, FileMode.Open, FileAccess.Read))
        {
            fileStream.Position = 0x3C;
            fileStream.Read(buffer, 0, 4);
            fileStream.Position = BitConverter.ToUInt32(buffer, 0); // COFF header offset
            fileStream.Read(buffer, 0, 4); // "PE\0\0"
            fileStream.Read(buffer, 0, buffer.Length);
        }
        var pinnedBuffer = GCHandle.Alloc(buffer, GCHandleType.Pinned);
        try
        {
            var coffHeader = (_IMAGE_FILE_HEADER)Marshal.PtrToStructure(pinnedBuffer.AddrOfPinnedObject(), typeof(_IMAGE_FILE_HEADER));
            return DateTimeOffset.FromUnixTimeSeconds(coffHeader.TimeDateStamp);
        }
        finally
        {
            pinnedBuffer.Free();
        }
    }
    else 
    {
        return null;
    }
}

修改后发现返回的是一个在2090年之后的日期，还是不对。

Deterministic Build 来背锅

这次的原因是MS在某个Roslyn版本中默认开启了Deterministic Build

….. The /deterministic flag causes the compiler to emit the exact same EXE / DLL, byte for byte, when given the same inputs.

既然输入相同输出必定相同，那可能会变的部分就只能固定下来了。例如时间戳。

… the MVID, PDB ID and Timestamp are the core issues to solve for deterministic builds.

MS选了一个比较折中的方案——由文件内容计算

Why not just use all 0s for the timestamp?

This is actually how the original implementation of determinism functioned in the compiler. Unfortunately it turned out there were a lot of tools we used in our internal process that validated the timestamp. They got a bit cranky when the discovered binaries claiming to be written in 1970, over 25 years before .NET was even invented. The practice of validating the time stamp is questionable but given tools were doing it there was a significant back compat risk. Hence we moved to the current computed value and haven’t seen any issues since then.

所以我们得到一个奇怪的值也是Work as expected了🙃

解决办法非常简单，在.csproj中将

`1`	`<deterministic>true</deterministic>`

改为

`1`	`<deterministic>false</deterministic>`

即可。需要注意的是，Deterministic Build在.NET Core上默认开启，要使PE头部的TimeDateStamp有意义需要将其关闭。而在.NET Framework上则是只有在VS2017的某个特定版本后新建的工程才会开启。

题外话，这个默认开启的Deterministic Build还搞出了其他幺蛾子，例如这里

引用类型的开销

Thu, 19 Jul 2018 20:26:05 +0000

值类型与引用类型

C#中的类型分为引用类型和值类型。使用struct或enum关键字修饰的类型定义是值类型，使用class或delegate关键字修饰的类型是引用类型。引用类型和值类型各有限制，分别适用于不同的场景。不同于C++，C#中的值类型只能分配在栈上*1，引用类型只能分配在GC堆上。C#中的GC是精确式GC，这就对GC堆上的指针有了一些要求。这是引用类型有开销的原因之一。

Sync block index 与 Type object pointer

读过C# vir CLR的同学会知道，引用类型的开销是Sync blockindex和Type object pointer。他们的长度是都是一个字长。即在32位CLR上是4字节，在64位CLR上是8字节。Sync block index在CLR中是用于实现lock,Monitor等线程同步原语，Type object pointer是指向当前对象运行时类型信息的一个指针。Sync block index与Type object pointer只在CLR层面存在，对C#程序来说是透明的。但是CLR将它们暴封装后露C#，例如线程同步原语和反射API。

特殊的类型-数组

C#中绝大部分类型的大小在编译期就可以确定，只要把对应的成员的大小相加即可

`1`	`SizeOf(T) = T.GetFields.Select(f=>f.IsClass?WordSize:Sizeof(f)).Sum();`

数组是个很特殊的存在，特殊在它的大小是与元素的类型和数量有关。数组的内存布局包含了所有的元素。(另一个这样的类型是string)。byte[4]和byte[3]的类型都是byte[]，然而它们的大小却不一样。我们这次就好仔细观察下数组

使用WinDBG

WinDBG是Windows下常用的Debugger。虽然是以调试非托管代码设计，但是加上相关的插件以后也可以用来调试托管代码。SOS.dll是一个提供托管代码调试支持的的插件。它同时支持CLR和CoreCLR。

安装好WinDBG后，就可以开始调试了。简单起见，这里使用如下代码。

namespace SOSFromEE
{
    class Program
    {
        const int Length = 10;
        static void Main(string[] args)
        {
            var ints = Enumerable.Range(1, Length).ToArray();
            var strs = ints.Select(i => i.ToString()).ToArray();
            Console.ReadLine();
            GC.KeepAlive(ints);
            GC.KeepAlive(strs);
            Console.Read();
        }
    }

}

在WinDBG中选择Launch对应的可执行程序即可。在第一个断点时CLR还没有加载，我们继续让程序运行，等到不再出现ModLoad相关的提示时就可以让程序暂停了。我们在这时加载SOS扩展。

`1`	`.loadby sos CLRNameHere`

sos后跟的是CLR的名称

CLR2.0(.Net framework 3.5及以前)是mscorwks
CLR4.0(.Net framework 4.0及以后)是clr
.net core是 coreclr

加载模块的过程中需要从微软的服务器上下载相关的pdb文件。由于你懂的原因需要很长时间

CLR2.0 下的数组

我们首先在32位的CLR2.0下观察。

首先使用.loadby sos mscorwks加载SOS扩展模块。

!dumpheap -type TypeNameHere命令可以查看当前托管堆上类型名为TypeNameHere的对象。

`System.String[]`

我们先看看String[]都有哪些:

0:006> !dumpheap -type System.String[]

 Address       MT     Size
03591390 78ae46e4       80     
..........................
total 17 objects
Statistics:
      MT    Count    TotalSize Class Name
78ae46e4       17          676 System.Object[]
Total 17 objects

Address显示的是对象在托管堆中的地址，Method Table就是上文中说的Type object pointer了。

我们查看下位于地址03591390的String[]:

0:006> !dumparray 03591390

Name: System.String[]
MethodTable: 78ae46e4
EEClass: 788cda74
Size: 80(0x50) bytes
Array: Rank 1, Number of elements 16, Type CLASS
Element Methodtable: 78b10f14
[0] 035911c8
[1] 03591250
[2] null
[3] null
[4] null
[5] null
[6] null
[7] null
[8] null
[9] null
[10] null
[11] null
[12] null
[13] null
[14] null
[15] null

可以看到这个数组一共有16个元素，元素的类型是string。

我们再来看看03591390位置的内存布局

0:006> dd 03591390 -0x4

0359138c  00000000 78ae46e4 00000010 78b10f14
0359139c  035911c8 03591250 00000000 00000000
035913ac  00000000 00000000 00000000 00000000
035913bc  00000000 00000000 00000000 00000000
035913cc  00000000 00000000 00000000 00000000

dd 03591390 -0x4告诉WinDBG从03591390向前偏移4个字节的位置开始展示内存。之所以向前偏移4个字节是为了展示引用类型的开销。0359138c位置的值00000000是Sync block index，位于03591390的78ae46e4看起来有点摸不着头脑，在WinDBG的输出中查找后发现是System.String[]的MethodTable。

1
2

Name: System.String[]
MethodTable: 78ae46e4

MethodTable是CLR级别的概念，对应到这里就是Type Object Pointer。 GC堆上的对象往前偏４字节就能得到Sync block index，接下来是对象的Type object pointer。为了叙述方便，下文统称为对象头:)

由此推测，对象头长度是两个字长。起始位置为当前指针的位置往前偏移一个字长。有兴趣的同学可以在64位CLR上自行验证。

数组的长度是16(0x10)，地址03591395的值就是它。

地址03591388的78b10f14不知道是什么。没关系，CTRF+F查找后发现它在上文出现过。

`1`	`Element Methodtable: 78b10f14`

应该是String的Method table。

dump一下System.String:

0:006> !dumpheap -type System.String

      MT    Count    TotalSize Class Name
78b10f14      154         6224 System.String

看来猜得没错。总结一下，引用类型的数组有4字长的开销，分别是2字长的对象头，1字长的长度，1字长的元素类型指针

接下来看看值类型数组的布局

`System.Int32[]`

老样子，首先先找到堆上的Int32[].

0:006> !dumpheap -type System.Int32[]
 Address       MT     Size
03591e50 78b130b0      296     
................................
total 18 objects
Statistics:
      MT    Count    TotalSize Class Name
78b130b0       18         1440 System.Int32[]
Total 18 objects

dump一下相关属性

!dumparray 03591e50 
Name: System.Int32[]
MethodTable: 78b130b0
EEClass: 788ce6a8
Size: 296(0x128) bytes
Array: Rank 1, Number of elements 71, Type Int32
Element Methodtable: 78b13160

查看内存布局

0:006> dd 03591e50 -0x4
03591e4c  00000000 78b130b0 00000047 00000000
03591e5c  00000000 00000000 00000000 00000000
03591e6c  00000000 00000000 00000000 00000000
03591e7c  00000000 00000000 00000000 00000000
03591e8c  00000000 00000000 00000000 00000000
03591e9c  00000000 00000000 00000000 00000000
03591eac  00000000 00000000 00000000 00000000
03591ebc  00000000 00000000 00000000 00000000

首先Int32[]也有对象头和长度的开销，但是却没有元素类型指针的开销。

有心的同学可能已经发现了，Int32[]明确指出了元素的类型，而String[]却没有。

!dumparray 03591390
Name: System.String[]
MethodTable: 78ae46e4
EEClass: 788cda74
Size: 80(0x50) bytes
Array: Rank 1, Number of elements 16, Type *CLASS*

!dumparray 03591e50 
Name: System.Int32[]
MethodTable: 78b130b0
EEClass: 788ce6a8
Size: 296(0x128) bytes
Array: Rank 1, Number of elements 71, Type *Int32*

String[]的Type是个CLASS而不是String，难道说System.String[]是个’假的’的字符串数组？

….

恭喜你猜对了。使用!objsize命令发现String[]是个带了层皮的Object[]

!objsize 03591e50 
sizeof(03591e50) =          296 (       0x128) bytes (System.Int32[])
0:006> !objsize 03591390 
sizeof(03591390) =          392 (       0x188) bytes (System.Object[])

C# in depth中对泛型有这样的描述

对于一个泛型类MyGeneric<T>，对于T的是引用类型的情况，JIT只会为其生成一份代码;对于T是值类型的情况，则为每一个不同的T生成各自的代码。其中的原因是，在JIT运行时，指针的长度总是固定的，因而可以共用一套代码相同的代码。而值类型的长度是不确定的，因此需要为每个值类型单独生成代码。

这里可能也是相同的原因吧。指针的长度相同，因而才需要储存元素的类型指针，实现类型检查。而值类型的代码不共用，所以不需要储存元素的类型指针。

本来到已经可以结束了，可是我在32位的CLR4.0观察到的结果却不太一样。

CLR 4.0下的数组

与CLR 2.0不同，CLR 4.0下加载SOS的名字是clr

.loadby sos clr

`System.String[]`

首先dumpheap：

0:006> !dumpheap -type System.String[]
 Address       MT     Size
02531590 6979dfe0       84     
...........................
Statistics:
      MT    Count    TotalSize Class Name
6979dfe0       24          912 System.String[]
Total 24 objects

然后是dumparray:

Name:        System.String[]
MethodTable: 6979dfe0
EEClass:     69374b80
Size:        84(0x54) bytes
Array:       Rank 1, Number of elements 18, Type CLASS
Element Methodtable: 6979d488
[0] 02531254

最后dd:

0:006> dd 02531590 -0x4
0253158c  00000000 6979dfe0 00000012 02531254
0253159c  025312d8 00000000 00000000 02531568
025315ac  00000000 00000000 00000000 00000000
025315bc  00000000 00000000 00000000 00000000
025315cc  00000000 00000000 00000000 00000000
025315dc  00000000 00000000

位于02531598的值02531254是第一个元素的值而不是String的Method Table!

!dumpheap -type String
Statistics:
      MT    Count    TotalSize Class Name
6979d488      193         5932 System.String
Total 224 objects

CLR 4.0把Method Table去掉了？

经过简单的算术，确实是这样的 18个元素，占据空间18*4=72。

对象头和数组大小占据2*4+4=12

84=72+12，跟dumparray出来的值一样。(有兴趣的同学根据上文中CLR2.0的数据计算下)

!objsize也确认了我们的猜测

1
2

0:006> !objsize 02531590
sizeof(02531590) = 428 (0x1ac) bytes (System.String[])

`System.Int32[]`

!dumpheap:

0:006> !dumpheap -type System.Int32[]
 Address       MT     Size
02531f1c 6979f2a0      300     
.............................. 
Statistics:
      MT    Count    TotalSize Class Name
6979f2a0       20          844 System.Int32[]
Total 20 objects

!dumparray:

0:006> !dumparray 02531f1c 
Name:        System.Int32[]
MethodTable: 6979f2a0
EEClass:     693752d8
Size:        300(0x12c) bytes
Array:       Rank 1, Number of elements 72, Type Int32
Element Methodtable: 6979f2dc
[0] 02531f24
[1] 02531f28

dd:

0:006> dd 02531f1c -0x4
02531f18  00000000 6979f2a0 00000048 00000003
02531f28  00000007 0000000b 00000011 00000017
02531f38  0000001d 00000025 0000002f 0000003b
02531f48  00000047 00000059 0000006b 00000083
02531f58  000000a3 000000c5 000000ef 00000125
02531f68  00000161 000001af 00000209 00000277
02531f78  000002f9 00000397 0000044f 0000052f
02531f88  0000063d 0000078b 0000091d 00000af1

值类型数组倒是没有什么变化。

总结

C#中引用类型有2个字长的对象头开销。分别是Sync block index和Type Object Pointer。数组是特殊的类型，它的大小与包含的元素相关，因此具有额外的开销。

在CLR 2.0下
- 引用类型的数组包含额外的2字长的开销。分别是长度和元素的类型指针
- 值类型的数组包含长度的额外开销开销。大小是一个字长。
在CLR 4.0和CoreCLR中
- 引用类型和值类型的数组包含长度的额外开销开销。大小是一个字长。

限于篇幅，CoreCLR的情况不再赘述，还请读者自行验证。

/*其实本来看到Stackoverflow的回答只是想自己验证下的，但是自己动手的结果和答案里提到的不太一样，查了原因发现答案里用的是CLR2.0，我自己用的是CLR4.0。这就挖出来了CLR实现的更改。CoreCLR里使用的是CLR4.0里的规则。目前还不清楚MS为何要改实现*/

参考

记一次愉(dan)快(teng)的捉虫

Mon, 21 May 2018 21:03:59 +0000

废话

BUG是任何软件都会遇到的问题。它通常是开发人员考虑问题不全面而埋下的隐形炸弹，在条件合适的时候就会爆炸；开发自己埋BUG往往比较容易除错，因为代码都是自己写的，定位问题后git blame一下就可以甩锅了；而程序依赖项里的BUG则排查起来则让人一筹莫展，尤其是在没有足够多信息的情况。

面对来自客户和QA的压力，绞尽脑汁仍无法定位问题开发们只能找借口了🤣

It’s a feature,not a bug.
That’s the design decision, so not a bug

我以前也遇到框架出问题的情况，不过都是自己改代码改出来的，倒也不是很难排查。但这次挖出来的BUG就完全不一样了

背景

一个WPF的项目，勉强在deadline之前赶完了功能。出了新版本后接到QA报告，程序在Windows 8.1上死于OOM:

System.OutOfMemoryException: Insufficient memory to continue the execution of the program. at System.Windows.Media.MediaContext.NotifyPartitionIsZombie(Int32 failureCode) at System.Windows.Media.MediaContext.NotifyChannelMessage() at System.Windows.Interop.HwndTarget.HandleMessage(Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler) at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler) at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter) at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.Run()

捉虫

出师不利

程序里用自定义的Window Style替代了WPF自带的。但是自定义的Window Style在最大化的时候会覆盖任务栏。为了解决这个问题，我们使用了回答里自定义的消息循环。看到调用栈里的Hwnd，初步怀疑是自定义的消息循环的问题。把消息循环相关的代码拿掉，问题依旧。看来不是消息循环的问题。不过为什么我在开发的时候没有遇到问题呢？

寻找原因

把出问题版本直接放在我的开发机上跑发现并没有问题。放在另一个同事的机子上也没问题。这时候意识到问题有点蹊跷。一般来说这种不能稳定重现的问题都或多或少会和多线程和死锁有关。然而上个版本到这个版本并没有写这些方面的代码。这时候开始怀疑是环境的问题了。找来各个版本的Windows，依次尝试后发现只在Windows 8.1上有问题。难道是OS的问题？同事提醒了一句，说以前的版本是可以在Windows 8.1上正常跑的。用二分法，找到了最晚的能用的版本B和最早的不能用的版本A。

又入困境

按理说，找到版本后diff下改动的代码就能比较快的定位问题了。不过现在有了稳定浮现的版本B，我决定从异常本身入手。一番搜索后找到了微软的一篇博客，其中提到这个错误通常是渲染子系统出问题的症状：

… WPF render thread encountered some fatal error … Most of the time, a failure occurs when calling into DirectX/D3D … When a failure is detected, The render thread will attempt to map the failure it receives to an appropriate managed exception. The render thread only synchronizes with the UI thread in a few locations …The most common locations when they synchronize are … or as a result of the UI thread handling a “channel” message from DirectX.

If a render thread failure manifests as a System.OutOfMemoryException, then the likelihood is that the render thread was a victim of the process exhausting some resource .The exhausted resource is most often available/contiguous virtual address space … It might be a situation where sometimes the WPF render thread is the victim of the resource exhaustion …

WPF里的渲染是由非托管的DirectX做的。为了从程序员的角度隐藏掉渲染这个过程，WPF将自身拆分为不同的组件。PreserentationFramework.dll和PreserentationFrameworkCore.dll是程序员直接能接触到的。这里实现的是组合子系统。渲染子系统则在非托管的milcore.dll里实现。System.Windows.Media.Visual是WPF组合子系统的入口点，它通过私有的通信协议与milcore里的渲染子系统通信，从而将组合子系统和渲染子系统连接起来。

看起来我们的代码耗尽了DirectX里边的某种资源，从而让渲染失败了。C#做为一个托管语言，居然能捅这么大的篓子，完全不科学。这个BUG越来越有意思了🤔

既然异常上看不出来什么头绪那就要从代码入手了。找diff的时候发现B版本没有打tag。

没打tag不算大问题，多花了些时间成功找到了那个commit，但是心情有点不爽。

diff的代码不多。排除掉无关的文件就只剩下一些布局文件比较可疑。改流程，依次跳过这些页面，发现一跳到登录页面就挂了。登录页面的diff有点多，二分删除很快就定位到了问题的根源:ImageButton。

ImageButton是个在普通、鼠标悬停、被按下三种不同状态时显示不同的图片的按钮。

ImageButton.cs:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;

namespace Debugging
{
    public class ImageButton : Button
    {
        public ImageSource Source
        {
            get { return (ImageSource)GetValue(SourceProperty); }
            set { SetValue(SourceProperty, value); }
        }

        public static readonly DependencyProperty SourceProperty =
            DependencyProperty.Register("Source", typeof(ImageSource), typeof(ImageButton), new PropertyMetadata(null));

        public ImageSource MouseOverImage
        {
            get { return (ImageSource)GetValue(MouseOverImageProperty); }
            set { SetValue(MouseOverImageProperty, value); }
        }

        public static readonly DependencyProperty MouseOverImageProperty =
            DependencyProperty.Register("MouseOverImage", typeof(ImageSource), typeof(ImageButton), new PropertyMetadata(null));

        public ImageSource PressedImage
        {
            get { return (ImageSource)GetValue(PressedImageProperty); }
            set { SetValue(PressedImageProperty, value); }
        }

        public static readonly DependencyProperty PressedImageProperty =
            DependencyProperty.Register("PressedImage", typeof(ImageSource), typeof(ImageButton), new PropertyMetadata(null));
    }
}

ImageButton.xaml:

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:local="clr-namespace:Debugging">
    <Style TargetType="local:ImageButton">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="local:ImageButton">
                    <Grid>
                        <Image x:Name="image" Source="{TemplateBinding Source}" />
                    </Grid>
                    <ControlTemplate.Triggers>
                        <Trigger Property="IsMouseOver" Value="True">
                            <Setter TargetName="image" Property="Source" Value="{Binding RelativeSource={RelativeSource TemplatedParent}, Path=MouseOverImage}" />
                        </Trigger>
                        <Trigger Property="IsPressed" Value="True">
                            <Setter TargetName="image" Property="Source" Value="{Binding RelativeSource={RelativeSource TemplatedParent}, Path=PressedImage}" />
                        </Trigger>
                    </ControlTemplate.Triggers>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

登陆页面中是这样使用ImageButton的:

1
2
3

....
<ImageButton Source="{StaticResource SomeImage}" MouseOverImage="{StaticResouce SomeOtherImage}" PressedImage="{StaticResources AnotherImage}" />
....

把Source="{StaticResource SomeImage}"这一句去掉就正常了。似乎它就是罪魁祸首。但是，把这部分代码和图片拿出来放到另一个程序里却又一切正常。

转机

接下来又尝试了

把ImageButton替换为Image
把Template.Trigger去掉
把SomeImage指向其他图片

但是还是找不到root cause。一模一样的代码不能在其他程序复现，那就说明BUG是我们程序自己造成的。但是这个BUG只在Windows 8.1下出现，说明跟环境也有可能有关系。距离发现BUG已经过去一天半了，放弃的话实在是不甘心，接下来只能猜了。

堆栈里显示程序挂在WPF的程序集里，基于这个现象决定retarget到.NET Framework的最新版本4.7.2。编译打包部署一套流程走完，在运行的时候发现Windows 8.1没有安装.NET Framework 4.7.2。好吧，那就装。可是安装包告诉我不满足条件：

需要安装KB2919355？

微软来背锅

在微软的支持网站上详细列出了KB2919355的change log。以image为关键字CTRL+F发现这样的描述：

Article number Article Title

2929755 Out of memory when you load some image resources in a Windows application

Article number	Article Title
2929755	Out of memory when you load some image resources in a Windows application

我去，这就是我们遇到的问题。

对应的页面给出的描述：

Symptoms

When you load some image resources in an application such as Microsoft Visual Studio on a computer that has Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, or Windows Server 2008 R2 installed, the application stops responding and memory leaks in Windows. This issue occurs after you install the following update: 2670838 Platform update for Windows 7 SP1 and Windows Server 2008 R2 SP1

File Information

For all supported x86-based versions of Windows 8:

File name File version File size Date Time Platform

Windowscodecs.dll 6.2.9200.16809 1,339,392 31-Jan-2014 00:48 x86

Windowscodecs.dll 6.2.9200.20930 1,319,936 31-Jan-2014 06:04 x86

File name	File version	File size	Date	Time	Platform
Windowscodecs.dll	6.2.9200.16809	1,339,392	31-Jan-2014	00:48	x86
Windowscodecs.dll	6.2.9200.20930	1,319,936	31-Jan-2014	06:04	x86

这个BUG是KB2670838引入的。在2670838的更新中,微软更新了现有的Windows Imaging Component (WIC)

This update improves the range and performance of the following graphics and imaging components:

Windows Imaging Component (WIC)

我们在diff里重点关注了Image相更改，发现改了这么一行：

<Application.Resources>
        <Style TargetType="Image">
            <Setter Property="RenderOptions.BitmapScalingMode"
                    Value="Fant" />
        </Style>
</Application.Resources>

RenderOptons.BitmapScalingMode指明在需要缩放时使用的算法。Fant是质量最高的一种之一。尝试Fant改为Linear后程序正常运行。继续尝试其他的值，发现除了Linear和Unspecified都会崩溃。

原因分析

在KB2670838里的WIC在特定情况会OOM爆掉。WPF里的BitmapScalingMode.Fant依赖WIC实现，在装了KB2670838的环境里跟就会跟WIC一起OOM爆掉；微软在后来发行的KB2919355中修复了这个BUG。

我们的测试机的Windows系统由RTM的镜像安装并且关闭了自动更新。在Windows 8.1之前的RTM镜像没有自带KBB2670838，在Windows 8.1之后RTM镜像自带了KB2919355。偏偏这个Windows 8.1的RTM镜像内置了KB2670838而没有内置KB2919355，程序就这样死于OOM。

验证Windowscodecs.dll的版本也支持这个结论。

总结

定位环境问题的时候要控制变量
二分法能快速定位出错的位置
打好Tag很重要
一直以来依赖的底层也会有BUG。大胆质疑，小心求证。

~~该甩锅的时候要果断的甩给微软~~

Reference

WPF Architecture - docs.microsoft.com

WPF ToolTip Rendering Issue : Application Hang - social.msdn.microsoft.com

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update: April 2014 - support.microsoft.com

Platform update for Windows 7 SP1 and Windows Server 2008 R2 SP1 - support.microsoft.com

Windows Imaging Component - msdn.microsoft.com

HTTPClient 踩坑记

Tue, 24 Oct 2017 19:43:28 +0000

HttpClient是随着.Net framework 4.5一起发布的现代Http库。比起WebClient，HttpClient最大的优点就是加入了C#5中的async/await异步方法的支持。async/await的坑暂且不表，今天就来说一说这个HttpClient

HttpClient的坑

HttpClient实现了IDisposable接口，很多小伙伴一看到IDisposeable接口就纷纷把HttpClient套在了using里边

//bad httpclient usage
using(var client = new HttpClient())
{
    //do stuffs
}

这种用法是错误的.HttpClient在设计之初被设计为一个可重用的对象，它的生命周期应该与应用程序相一致.上述错误的用法每发起一个请求就会创建一个新的HttpClient，并且在收到回复之后立即把HttpClient dispose掉。众所周知TCP连接在真正断开之前会有几分钟处于CLOSE_WAIT状态。这个状态下TCP链接并没有真正断开。短时间内大量发出Http请求会使系统可用的端口急剧消耗。

MS的人推荐重用HttpClient以使其生命周期与应用相同

//good httpclient usage
class GoodHttpClientSample
{
    private static readonly HttpClient client = new HttpClient();
    public Task<string> GetStringAsync(string url)
    {
        var resposne = await client.GetAsync(url).ConfigureAwait(false);
        return response.Content.ReadAsStringAsync();
    }
    
}

HttpClient的优点

踩过了坑我们再来说说他的好处。去掉async/await支持这个最大的有点，HttpClient的一个构造函数的重载接受一个HttpMessageHandler。这个重载很有意思。HttpMessageHandler可以在发出Http请求和接受Http回复时做出一些回应。.net framework里有一个类叫做DelegatingHandler，它继承了HttpMessageHandler。叫做DelegatingHandler是因为它有个类型为HttpMessageHandler的InnerHandler属性，因而可以把请求delegate给InnerHandler。通过这个DelegatingHandler我们可以请以实现像Java web里的filter chain一样的逻辑。

今天重构了公司的代码。公司现有的HttpManager提供了GET和POST两种Http动词的异步方法。在这些方法中还进行了日志记录和失败重试。日志记录和失败重试相关的代码非常重复，但是又无法写成一个函数。因此我把这部分逻辑抽出来做成了两个DelegatingHandler

class LogHandler:DelegatingHandler
{
    private readonly ILog _log;
    public LogHandler(ILog log,HttpMessageHandler handler):base(handler)
    {
        _log = log;
    }

    protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        try
        {
            var begin = DateTime.Now;
            _log.I($"{request.Method} ->{request.RequestUri}");
            var response = await base.SendAsync(request,cancellationToken);
            var end = DateTime.Now;
            var diff = (end-begin).TotalMillseconds;
            _log.I($"{request.Method} <- {response.Content.ReadAsStringAsync()} cost{diff}ms");
        }
        catch(Exception e)
        {
            _log.E($"{request.Method} ->{request.RequestUri},{e}");
            throw;
        }
    }

class RetryHandler:DelegatingHandler
{

    protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,CancellationToken cancellationToken)
    {
        HttpResponseMessage response = null;
        for(int i=0;i<=_retryTimes,i++)
        {
            try
            {
                response = await base.SendAsync(request,cancellationToken);
                return response;
            }
            catch(Exception)
            {
                if(i==_retryTimes)
                {
                    throw;
                }
            }
            //make compiler happy. 
            return response;
        }
        
    }
    private readonly int _retryTimes = 0;
    public RetryHandler(int retryTimes,HttpMessageHandler handler):base(handler)
    {
        if(retryTimes<0)
        {
            throw new ArgumentOutOfRangeException(nameof(retryTimes));
        }
        _retryTimes = retryTimes;
    }
}

HttpClientHandler是个真正实现HttpClient逻辑的HttpMessageHandler。因此，我们只要保证最内部的Handler时HttpClientHandler就OK了。

private static readonly ILog _log;

private static readonly HttpClient _client = new 
HttpClient(new RetryHandler(3,new LogHandler(_log,new HttpClientHandler())));

需要注意的是，如果HttpHandler没有返回HttpResponseMessage,对应的异步方法会在运行时抛出InvalidOperationException

重构之后整个Http封装类的代码行数从400行减少到了120行左右，可读性和可维护性提升显著。

C# on Melchior on CLR

Molecule to atoms

获取程序的编译时间

日常新需求

实现

Deterministic Build 来背锅

引用类型的开销

值类型与引用类型

Sync block index 与 Type object pointer

特殊的类型-数组

使用WinDBG

CLR2.0 下的数组

System.String[]

System.Int32[]

CLR 4.0下的数组

System.String[]

System.Int32[]

总结

参考

记一次愉(dan)快(teng)的捉虫

废话

背景

捉虫

出师不利

寻找原因

又入困境

转机

微软来背锅

原因分析

总结

Reference

HTTPClient 踩坑记

HttpClient的坑

HttpClient的优点

Further reading

`System.String[]`

`System.Int32[]`

`System.String[]`

`System.Int32[]`