为什么递归调用在不同的堆栈深度会导致堆栈溢出错误？

我试图亲自了解C#编译器如何处理尾调用。

（答案是：它们不会进行优化，但64位JIT(s)将进行尾调用消除。 有限制。）

因此，我编写了一个小测试，使用递归调用并打印在StackOverflowException终止进程之前调用了多少次。

class Program
{
    static void Main(string[] args)
    {
        Rec();
    }
    static int sz = 0;
    static Random r = new Random();
    static void Rec()
    {
        sz++;
        //取消注释以获得更快、更不准确的运行
        //if (sz % 100 == 0)
        {
            //用于防止此方法被内联的一些代码
            var zz = r.Next();  
            Console.Write("{0} Random: {1}\r", sz, zz);
        }
        //取消注释会阻止尾调用消除
        //else
        //{
        //    Console.Write("{0}\r", sz);
        //}
        Rec();
    }

准时地，程序在以下情况下以SO异常结束：

• 关闭“优化生成”（无论是Debug还是Release）
• 目标：x86
• 目标：AnyCPU + “首选32位”（这是VS 2012中的新功能，也是我第一次看到。 更多信息请查看。）
• 代码中的某些看似无害的分支（请参见已注释的“else”分支）。

相反，使用“优化生成”+（目标= x64或具有关闭“首选32位”的AnyCPU（在64位CPU上）），尾调用消除会发生，并且计数器将无限增加（好吧，可以说每次值溢出时会减小）。

但我注意到一个无法解释的行为在StackOverflowException的情况下：它永远不会在完全相同的堆栈深度发生（可能）。以下是几次32位运行的输出，Release生成：

51600 Random: 1778264579
由于StackOverflowException终止进程。
51599 Random: 1515673450
由于StackOverflowException终止进程。
51602 Random: 1567871768
由于StackOverflowException终止进程。
51535 Random: 2760045665
由于StackOverflowException终止进程。

和Debug生成：

28641 Random: 4435795885
由于StackOverflowException终止进程。
28641 Random: 4873901326  //永远不要说永远
由于StackOverflowException终止进程。
28623 Random: 7255802746
由于StackOverflowException终止进程。
28669 Random: 1613806023
由于StackOverflowException终止进程。

堆栈大小是恒定的（默认为1MB）。堆栈帧的大小是恒定的。

那么，当StackOverflowException发生时，堆栈深度的（有时非凡的）变化可以由什么解释？

更新

Hans Passant提出了Console.WriteLine触及P/Invoke、互操作和可能是非确定性锁定的问题。

因此，我将代码简化为以下内容：

class Program
{
    static void Main(string[] args)
    {
        Rec();
    }
    static int sz = 0;
    static void Rec()
    {
        sz++;
        Rec();
    }
}

我在Release/32bit/Optimization ON的情况下运行它，没有调试器。当程序崩溃时，我附加调试器并检查计数器的值。

然而，即使在多次运行中，它的值仍然不同（或者我的测试有缺陷）。

更新：封闭

正如fejesjoco建议的那样，我研究了ASLR（地址空间布局的随机化）。

这是一种安全技术，通过随机化进程地址空间中的各种内容，包括堆栈位置和大小，使得缓冲区溢出攻击难以找到（例如）特定系统调用的精确位置。

理论听起来很好。让我们实践一下吧！

为了测试这一点，我使用了一个专门用于此任务的微软工具：EMET或Enhanced Mitigation Experience Toolkit。它允许在系统或进程级别设置ASLR标志（还有更多）。

（还有一个系统范围的注册表修改替代方案，我没有尝试）

为了验证工具的有效性，我还发现Process Explorer在进程的“属性”页面上报告了ASLR标志的状态。直到今天我才看到这个 🙂

理论上，EMET可以在单个进程中（重新）设置ASLR标志。实际上，它似乎没有改变任何事情（见上图）。

但是，我为整个系统禁用了ASLR，并且（重启后）我终于验证了确实，SO异常现在总是在相同的堆栈深度发生。

奖励

与ASLR相关的较旧新闻：Chrome是如何被攻破的