Author Archives: youenzeng

调试ASP.NET Core 源代码

今天在Stackoverflow上面看到一个Routing相关的问题, 看起来和想的不一样, 于是想调试下代码看看里面的细节, 结果发现非常方便,所以分享下。

我最开始的想法是从Github上面下载源码,然后Attach to Process.

先关掉Just My Code这个开关。PS: 没需要不要关这个开关,会让调试变慢。

于是开始动手,本地dotnet new webapidotnet build xx.sln, dotnet xx.dll

从github下载源码,https://github.com/aspnet/Mvc.git,打开后切换至对应版本的release分支。

后面就直接attach 到 dotnet.exe

此时断点是不亮的,如提示,没有加载运行所需的PDB文件: 'dotnet.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.3\Microsoft.AspNetCore.dll'. Cannot find or open the PDB file., 我们可以去巨硬的symbol server下载, 在Visual Studio中,Debug->Windows->Modules,找到要调试的DLL, 右键Load Symbols即可。

这样就断点亮起来,就可以继续调试了。

后面发现更方便的办法就是直接在Module里面Load symbols,如果本地没有源码,VS会提示是否要下载源码,不过如果要完整调试的话,需要下载好多次的感觉,还是把代码仓库搬下来省事。

自动触发Breakpoint

曾经有段时间在跟一个Windows service作斗争, 但是我想调试它的startUp事件代码, 没法进去。 后来找到个方法就是 System.Diagnostics.Debugger.Launch();,这样就可以服务在启动的时候就是提示你进入断点了。 正好最近在参与一个比较复杂且混乱的项目,利用这个可以很方便地触发想调试的代码。

namespace Canary
{
    class Program
    {
        static void Main(string[] args)
        {

            System.Diagnostics.Debugger.Launch();
            Console.WriteLine("Hello World!");
        }
    }
}

执行后

同理, JavaScript里面是用 debugger; 来触发。

附上断点的工作原理, 在hack news上看到的 https://majantali.net/2016/10/how-breakpoints-are-set/

&,&&,|,|| 区别

一图流!

string a = "test", b;
a == "test" || b.ToString() == "test"
true
a == "test" | b.ToString() == "test"
Object reference not set to an instance of an object.

a!="test" && b.ToString()!="test"
false
a!="test" & b.ToString()!="test"
Object reference not set to an instance of an object.

如上面所示 &&,|| 为逻辑与或, 使用了短路计算(short circuit evaluation), 即当第一个条件可以判断出结果时, 不考虑后面的条件. 比如 a && b, 当 a=false时, 返回false,不会查看b的值.

而&,| 适用于bool 和 int, 返回的是其按位与或的结果. 无论第一个条件如何, 都会计算第二个条件, 然后得出结果.

参考(好吧.其实我是查找短路的时候找到这篇wiki的, 没法往下写了,人家都写好了..): https://en.wikipedia.org/wiki/Short-circuit_evaluation

DotNet Framework 源码阅读记录

Dotnet Core最近发布了2.1版本,相信也更加趋于稳定了。 虽然我接触.NET是从3.5+开始,不过这次可以从1.0开始见证它的发展了。 最近闲的时候阅读了一部分源码,虽然之前也看过不少,不过没有记录。 现在有了博客,就记录一点。

主要看的是下面几个仓库里面的内容:

Void 是个结构体(Struct)

Public struct Void{}

AggregateException

AggregateException 是伴随着async/await引入的新的类型, 有个Flatten方法, 可以将内部异常展开(貌似是BFS算法). 在调用时,将内部异常保存在一个ReadOnlyCollection中,不可改变. –> See how stack trace generated

DBNull

DbNull.Value is an instance of DbNull type. ToString() => string.Empty
Inheriated from Iconvertible, all other convertation will throw exception. InvalidCastException

DateTime

使用大量的缓存
* Days per 100 years/400years
* 里面存储了dates to 1601/1899/1970/10000,因为对应了不同的纪元 -> https://en.wikipedia.org/wiki/Epoch_(reference_date)
* Ticks per ms/s/Minute/Hour/Day
* s_daysToMonth365/s_daysToMonth366

字典

Dictionay – hash with chaining
HashTable – hash using open addressing

Overflow检测

在数字一部分, 有一段很精妙的overflow检测方式, 在做算法题的时候会用到。

        public static int Abs(int value)
        {
            if (value < 0)
            {
                value = -value;
                if (value < 0)
                {
                    ThrowAbsOverflow();
                }
            }
            return value;
        }

以及几个有意思的常量, 对于自己设计框架有帮助。

        public const double NegativeInfinity = (double)-1.0 / (double)(0.0);
        public const double PositiveInfinity = (double)1.0 / (double)(0.0);
        public const double NaN = (double)0.0 / (double)0.0;

Span

Span<T> https://msdn.microsoft.com/en-us/magazine/mt814808.aspx

DebuggerTypeProxy

在设计框架里面的类型时, 可以使用DebuggerTypeProxy在debugger里面显示的内容。

炉石传说卡组代码生成机制

炉石传说套牌代码分析

炉石传说可以共享套牌了,复制一串代码在炉石里面就可以直接导入,有了系统的支持,导入套牌就方便多了。那么这串字符是如何生成的呢? 经过一些分析和学习,记录如下。

我在HearthSim这个网站上找到了相关的分析和代码,https://hearthsim.info/docs/deckstrings/ 。这个网站提供了几个编程语言的生成代码,以C#版本的为例做分析。

代码

仓库地址: https://github.com/HearthSim/HearthDb。拖下来编译时,它会再去获取另外一个炉石数据库仓库: https://github.com/HearthSim/hsdata

有了这2个仓库后, 代码就可以正常运行了。在接触陌生的代码时,了解其功能除了读文档外,就是阅读测试代码了。
PS:里面有俩项目Build会失败,组件引用冲突错乱,无视即可。只需Build HearthDB

通过阅读测试方法TestDeckStrings,可以对这段字符有个大概了解。

[TestMethod]
public void TestDeckStrings()
{
    var deck = DeckSerializer.Deserialize(DeckString);
    Assert.AreEqual(CardIds.Collectible.Warrior.GarroshHellscream, deck.GetHero().Id);
    var cards = deck.GetCards();
    Assert.AreEqual(30, cards.Values.Sum());
    var heroicStroke = cards.FirstOrDefault(c => c.Key.Id == CardIds.Collectible.Warrior.HeroicStrike);
    Assert.IsNotNull(heroicStroke);
    Assert.AreEqual(2, heroicStroke.Value);
}

可以看到字符解析为byte数组,然后对其顺序遍历解析,具体分析见下图。

AAECAQcCrwSRvAIOHLACkQP/A44FqAXUBaQG7gbnB+8HgrACiLACub8CAA==

byte[43] {
0,                +--------->   placeholder
1,                |--------->   version always 1
2,                |--------->   FormatType
1,                |--------->   Num Heroes + always 1
7,                |--------->   HeroId
2,                +--------->   numSingleCards
175, 4,         + |
145, 188, 2,    + +-------------> single card part
14,               +---------^   numDoubleCards
28,           +
176, 2,       |
145, 3,       |
255, 3,       |
142, 5,       |
168, 5,       |
212, 5,       |
164, 6,       |  +----------->  double cards part
238, 6,       |
231, 7,       |
239, 7,       |
130, 176, 2,  |
136, 176, 2,  |
185, 191, 2,  +
0                 +----------->  multi cards (more than 2) count
}

PS: 我是用了ASCII Flow,效果看起来还不错. http://asciiflow.com/

数字的编码:Base 128 Varints

值得一提的是里面的卡牌编号是由1~3个byte推算出来的,比如 175, 4 是一张卡,由于采用的是short int,占用2个Byte; 145, 188, 2 是另外一张卡,占用3个byte, 而不是每个占用4个byte。这样大幅度缩减了字符串的长度,尤其是老版本卡牌宇宙卡组:) ,因为早版本的卡编号较小。这个数字是如何生成的呢?我们可以在VarInt这个类里面找到。

生成

while(value != 0)
{
    var b = value & 0x7f;
    value >>= 7;
    if(value != 0)
        b |= 0x80;
    ms.WriteByte((byte)b);
}

解析

ulong result = 0;
foreach(var b in bytes)
{
    var value = (ulong)b & 0x7f;
    result |= value << length * 7;
    if((b & 0x80) != 0x80)
        break;
}

乍一看,有点难懂,由于算的时候shift了7个bit,不难看出这个是128进制的表示方法,不过与我们常见的进制转换算法略有不同,这里使用了|= 0x80记录了一个最高有效位(most significant bit (msb) )来标识一个数字是否结束。这个自解释的信息,使得连续数字不需要其他分隔符,因为当我们读到没有MSB时,就知道这个数字标识到头了,下一个读到的新的数字的部分。这种表示方法,是倒序表示的,即低位在前面,随后读到高位然后加和得到结果。

Protocol buffers中使用了这种编码方式:https://developers.google.com/protocol-buffers/docs/encoding, 这样可以节省不少流量,不过消耗的CPU资源如何呢?