C#：如何测试 StackOverflowException

Question

假设您有一个方法可能会陷入无限的方法调用循环并因 StackOverflowException 崩溃。例如，这个问题中提到的我天真的RecursiveSelect方法< /a>.

从 .NET Framework 2.0 版开始，try-catch 块无法捕获 StackOverflowException 对象，并且默认情况下会终止相应的进程。因此，建议用户编写代码来检测和防止堆栈溢出。例如，如果您的应用程序依赖于递归，请使用计数器或状态条件来终止递归循环。

获取该信息（来自这个答案< /a>) 考虑到，由于无法捕获异常，是否有可能为这样的事情编写测试？或者，如果测试失败，是否会真正破坏整个测试套件？

注意：我知道我可以尝试一下，看看会发生什么，但我对有关它的一般信息更感兴趣。比如，不同的测试框架和测试运行程序会以不同的方式处理这个问题吗？即使有可能，我是否应该避免这样的测试？

Answer 1

您需要解决停止问题！这会让你变得富有和出名:)

Answer 2

在断言语句中检查堆栈上的帧数怎么样？

const int MaxFrameCount = 100000;
Debug.Assert(new StackTrace().FrameCount < MaxFrameCount);

在相关问题的示例中，这将是（昂贵的断言语句将在发布版本中删除）：

public static IEnumerable<T> SelectRecursive<T>(this IEnumerable<T> subjects, Func<T, IEnumerable<T>> selector)
{
    const int MaxFrameCount = 100000;
    Debug.Assert(new StackTrace().FrameCount < MaxFrameCount);

    // Stop if subjects are null or empty
    if(subjects == null || !subjects.Any())
        yield break;

    // For each subject
    foreach(var subject in subjects)
    {
        // Yield it
        yield return subject;

        // Then yield all its decendants
        foreach (var decendant in SelectRecursive(selector(subject), selector))
            yield return decendant;
    }
}

但这不是一般测试，因为您需要预期它会发生，而且您只能检查帧数而不能堆栈的实际大小。也不可能检查另一个调用是否会超出堆栈空间，您所能做的就是粗略估计堆栈上总共有多少个调用。

Answer 3

这是邪恶的，但你可以在新的进程中旋转它。从单元测试启动该过程并等待其完成并检查结果。

Answer 4

这个想法是跟踪递归函数的嵌套深度，这样它就不会使用太多的堆栈空间。示例：

string ProcessString(string s, int index) {
   if (index > 1000) return "Too deeply nested";
   s = s.Substring(0, index) + s.Substring(index, 1).ToUpper() + s.Substring(index + 1);
   return ProcessString(s, index + 1);
}

这当然不能完全保护您免受堆栈溢出的影响，因为可以在开始时剩余的堆栈空间太少的情况下调用该方法，但它可以确保该方法不会单独导致堆栈溢出。

Answer 5

我们无法对 StackOverflow 进行测试，因为这是当没有更多堆栈可供分配时的情况，应用程序将在这种情况下自动退出。

Answer 6

如果您正在编写其他人要使用的库代码，则堆栈溢出往往比其他错误更严重，因为其他代码不能仅仅吞掉 StackOverflowException ；他们的整个过程正在下降。

没有简单的方法来编写期望并捕获 StackOverflowException 的测试，但这不是您想要测试的行为！

以下是一些测试代码不会堆栈溢出的提示：

• 并行化您的测试运行。如果您有一个单独的测试套件来处理堆栈溢出情况，那么即使一个测试运行程序出现故障，您仍然可以获得其他测试的结果。 （即使您不分离测试运行，我也认为堆栈溢出非常严重，如果发生这种情况，值得使整个测试运行程序崩溃。您的代码一开始就不应该中断！）

• 线程可能有不同数量的堆栈空间，如果有人调用您的代码，您无法控制有多少堆栈空间可用。虽然 32 位 CLR 的默认堆栈大小为 1MB，64 位 CLR 的默认堆栈大小为 2MB，但请注意 Web 服务器将默认为更小的堆栈。您的测试代码可以使用 Thread 之一 如果您想验证代码不会在可用空间较少的情况下使用较小堆栈大小的构造函数。

• 测试您提供的每种不同的构建风格（发布和调试？带或不带调试符号？x86 和 x64 和 AnyCPU？）以及您将支持的平台（64 位？32 位？运行 32 位的 64 位操作系统？。 NET 4.5？3.5？）。生成的本机代码中堆栈帧的实际大小可能不同，因此一台机器上的中断可能不会在另一台机器上中断。

• 由于您的测试可能在一台构建机器上通过，但在另一台构建机器上失败，请确保如果它开始失败，它不会阻止整个项目的签入！

• 一旦测量了导致代码堆栈溢出的迭代次数 N 的次数，不要只测试这个数字！我会测试更大数量（50 N？）的迭代不会堆栈溢出（因此您不会得到在一个构建服务器上通过但在另一台构建服务器上失败的测试）。

• 考虑函数最终可以调用自身的每个可能的代码路径。您的产品可能会阻止 X() -> X()-> X()-> ... 递归堆栈溢出，但是如果有 X() -> A()-> B()-> C()-> ...-> W()-> X()-> A()-> ... 仍然有问题的递归情况？

PS：我没有关于此策略的更多详细信息，但显然如果您的代码 托管 CLR 那么您可以指定堆栈溢出仅使 AppDomain 崩溃吗？

Answer 7

首先也是最重要的，我认为该方法应该处理这个问题并确保它不会递归得太深。

完成此检查后，我认为应该通过暴露达到的最大深度并断言它永远不会大于检查允许的深度来测试检查（如果有的话）。