如何防止和/或处理 StackOverflowException？

Question

我想阻止或处理在 Xsl Editor 中调用 XslCompiledTransform.Transform 方法时遇到的 StackOverflowException。写作。 问题似乎是用户可以编写无限递归的 Xsl 脚本，并且它在调用 Transform 方法时就会崩溃。 （也就是说，问题不仅仅是典型的编程错误，这通常是导致此类异常的原因。）

有没有办法检测和/或限制允许的递归次数？ 或者还有其他想法可以防止这段代码在我身上爆炸吗？

Answer 1

来自微软：

从 .NET Framework 开始
2.0 版，StackOverflowException
try-catch 无法捕获对象
块，对应的进程是
默认终止。 最后，
建议用户编写自己的代码
检测并防止堆栈
溢出。 例如，如果您的
应用程序取决于递归，使用
计数器或状态条件
终止递归循环。

我假设异常发生在内部 .NET 方法中，而不是在您的代码中。

你可以做几件事。

• 编写代码来检查 xsl 是否存在无限递归，并在应用转换之前通知用户（呃）。
• 将 XslTransform 代码加载到单独的进程中（Hacky，但工作量较少）。

您可以使用 Process 类加载程序集，该程序集会将转换应用到单独的进程中，并在进程终止时提醒用户失败，而无需终止您的主应用程序。

编辑：我刚刚测试过，这是如何做到的：

MainProcess：

// This is just an example, obviously you'll want to pass args to this.
Process p1 = new Process();
p1.StartInfo.FileName = "ApplyTransform.exe";
p1.StartInfo.UseShellExecute = false;
p1.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;

p1.Start();
p1.WaitForExit();

if (p1.ExitCode == 1)    
   Console.WriteLine("StackOverflow was thrown");

ApplyTransform Process：

class Program
{
    static void Main(string[] args)
    {
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
        throw new StackOverflowException();
    }

    // We trap this, we can't save the process, 
    // but we can prevent the "ILLEGAL OPERATION" window 
    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        if (e.IsTerminating)
        {
            Environment.Exit(1);
        }
    }
}

Answer 2

注意@WilliamJockusch 的赏金问题和原始问题是不同的。

这个答案是关于 StackOverflow 在第三方库的一般情况下以及你可以/不能用它们做什么。 如果您正在寻找 XslTransform 的特殊情况，请参阅已接受的答案。

---

堆栈溢出是由于堆栈上的数据超出一定限制（以字节为单位）而发生的。 有关此检测工作原理的详细信息，请参阅此处。

我想知道是否有一种通用方法可以跟踪 StackOverflowExceptions。 换句话说，假设我的代码中某处有无限递归，但我不知道在哪里。 我想通过某种方式来追踪它，这比在整个地方逐步执行代码直到我看到它发生更容易。 我不在乎它有多黑客。

正如我在链接中提到的，从静态代码分析中检测堆栈溢出需要解决不可判定的停止问题。 既然我们已经确定没有灵丹妙药，我可以向您展示一些我认为有助于解决问题的技巧。

我认为这个问题可以用不同的方式解释，因为我有点无聊:-)，我会将它分解为不同的变体。

在测试环境中检测堆栈溢出

基本上，这里的问题是您有一个（有限的）测试环境，并且想要在（扩展的）生产环境中检测堆栈溢出。

我没有检测 SO 本身，而是通过利用堆栈深度可以设置的事实来解决这个问题。 调试器将为您提供所需的所有信息。 大多数语言允许您指定堆栈大小或最大递归深度。

基本上，我尝试通过使堆栈深度尽可能小来强制实现 SO。 如果它没有溢出，我总是可以将其增大（=在本例中：更安全）以适应生产环境。 当出现堆栈溢出时，您可以手动决定它是否是“有效”的。

为此，请将堆栈大小（在我们的例子中：一个小值）传递给线程参数，然后看看会发生什么。 .NET 中的默认堆栈大小为 1 MB，我们将使用更小的值：

class StackOverflowDetector
{
    static int Recur()
    {
        int variable = 1;
        return variable + Recur();
    }

    static void Start()
    {
        int depth = 1 + Recur();
    }

    static void Main(string[] args)
    {
        Thread t = new Thread(Start, 1);
        t.Start();
        t.Join();
        Console.WriteLine();
        Console.ReadLine();
    }
}

注意：我们也将使用下面的代码。

一旦溢出，您可以设置它到一个更大的值，直到你得到一个有意义的SO。

在执行此操作之前创建异常

StackOverflowException 是不可捕获的。 这意味着当事情发生时你无能为力。 因此，如果您认为代码中肯定会出现问题，那么在某些情况下您可以自己制定例外情况。 为此，您唯一需要的是当前堆栈深度； 不需要计数器，您可以使用 .NET 中的实际值：

class StackOverflowDetector
{
    static void CheckStackDepth()
    {
        if (new StackTrace().FrameCount > 10) // some arbitrary limit
        {
            throw new StackOverflowException("Bad thread.");
        }
    }

    static int Recur()
    {
        CheckStackDepth();
        int variable = 1;
        return variable + Recur();
    }

    static void Main(string[] args)
    {
        try
        {
            int depth = 1 + Recur();
        }
        catch (ThreadAbortException e)
        {
            Console.WriteLine("We've been a {0}", e.ExceptionState);
        }
        Console.WriteLine();
        Console.ReadLine();
    }
}

请注意，如果您正在处理使用回调机制的第三方组件，则此方法也适用。 唯一需要的是您可以拦截堆栈跟踪中的一些调用。

在单独的线程中进行检测

您明确建议了这一点，所以这里是这个。

您可以尝试在单独的线程中检测SO..但这可能不会对您有任何好处。 堆栈溢出可能很快发生，甚至在上下文切换之前也是如此。 这意味着这种机制根本不可靠...我不建议实际使用它。 不过构建起来很有趣，所以这里是代码:-)

class StackOverflowDetector
{
    static int Recur()
    {
        Thread.Sleep(1); // simulate that we're actually doing something :-)
        int variable = 1;
        return variable + Recur();
    }

    static void Start()
    {
        try
        {
            int depth = 1 + Recur();
        }
        catch (ThreadAbortException e)
        {
            Console.WriteLine("We've been a {0}", e.ExceptionState);
        }
    }

    static void Main(string[] args)
    {
        // Prepare the execution thread
        Thread t = new Thread(Start);
        t.Priority = ThreadPriority.Lowest;

        // Create the watch thread
        Thread watcher = new Thread(Watcher);
        watcher.Priority = ThreadPriority.Highest;
        watcher.Start(t);

        // Start the execution thread
        t.Start();
        t.Join();

        watcher.Abort();
        Console.WriteLine();
        Console.ReadLine();
    }

    private static void Watcher(object o)
    {
        Thread towatch = (Thread)o;

        while (true)
        {
            if (towatch.ThreadState == System.Threading.ThreadState.Running)
            {
                towatch.Suspend();
                var frames = new System.Diagnostics.StackTrace(towatch, false);
                if (frames.FrameCount > 20)
                {
                    towatch.Resume();
                    towatch.Abort("Bad bad thread!");
                }
                else
                {
                    towatch.Resume();
                }
            }
        }
    }
}

在调试器中运行它并享受所发生的事情。

利用堆栈溢出的特征

您的问题的另一种解释是：“可能导致堆栈溢出异常的代码片段在哪里？”。 显然，答案是：所有代码都带有递归。 对于每段代码，您都可以进行一些手动分析。

也可以使用静态代码分析来确定这一点。 为此，您需要做的是反编译所有方法并确定它们是否包含无限递归。 下面是一些为您执行此操作的代码：

// A simple decompiler that extracts all method tokens (that is: call, callvirt, newobj in IL)
internal class Decompiler
{
    private Decompiler() { }

    static Decompiler()
    {
        singleByteOpcodes = new OpCode[0x100];
        multiByteOpcodes = new OpCode[0x100];
        FieldInfo[] infoArray1 = typeof(OpCodes).GetFields();
        for (int num1 = 0; num1 < infoArray1.Length; num1++)
        {
            FieldInfo info1 = infoArray1[num1];
            if (info1.FieldType == typeof(OpCode))
            {
                OpCode code1 = (OpCode)info1.GetValue(null);
                ushort num2 = (ushort)code1.Value;
                if (num2 < 0x100)
                {
                    singleByteOpcodes[(int)num2] = code1;
                }
                else
                {
                    if ((num2 & 0xff00) != 0xfe00)
                    {
                        throw new Exception("Invalid opcode: " + num2.ToString());
                    }
                    multiByteOpcodes[num2 & 0xff] = code1;
                }
            }
        }
    }

    private static OpCode[] singleByteOpcodes;
    private static OpCode[] multiByteOpcodes;

    public static MethodBase[] Decompile(MethodBase mi, byte[] ildata)
    {
        HashSet<MethodBase> result = new HashSet<MethodBase>();

        Module module = mi.Module;

        int position = 0;
        while (position < ildata.Length)
        {
            OpCode code = OpCodes.Nop;

            ushort b = ildata[position++];
            if (b != 0xfe)
            {
                code = singleByteOpcodes[b];
            }
            else
            {
                b = ildata[position++];
                code = multiByteOpcodes[b];
                b |= (ushort)(0xfe00);
            }

            switch (code.OperandType)
            {
                case OperandType.InlineNone:
                    break;
                case OperandType.ShortInlineBrTarget:
                case OperandType.ShortInlineI:
                case OperandType.ShortInlineVar:
                    position += 1;
                    break;
                case OperandType.InlineVar:
                    position += 2;
                    break;
                case OperandType.InlineBrTarget:
                case OperandType.InlineField:
                case OperandType.InlineI:
                case OperandType.InlineSig:
                case OperandType.InlineString:
                case OperandType.InlineTok:
                case OperandType.InlineType:
                case OperandType.ShortInlineR:
                    position += 4;
                    break;
                case OperandType.InlineR:
                case OperandType.InlineI8:
                    position += 8;
                    break;
                case OperandType.InlineSwitch:
                    int count = BitConverter.ToInt32(ildata, position);
                    position += count * 4 + 4;
                    break;

                case OperandType.InlineMethod:
                    int methodId = BitConverter.ToInt32(ildata, position);
                    position += 4;
                    try
                    {
                        if (mi is ConstructorInfo)
                        {
                            result.Add((MethodBase)module.ResolveMember(methodId, mi.DeclaringType.GetGenericArguments(), Type.EmptyTypes));
                        }
                        else
                        {
                            result.Add((MethodBase)module.ResolveMember(methodId, mi.DeclaringType.GetGenericArguments(), mi.GetGenericArguments()));
                        }
                    }
                    catch { } 
                    break;
                

                default:
                    throw new Exception("Unknown instruction operand; cannot continue. Operand type: " + code.OperandType);
            }
        }
        return result.ToArray();
    }
}

class StackOverflowDetector
{
    // This method will be found:
    static int Recur()
    {
        CheckStackDepth();
        int variable = 1;
        return variable + Recur();
    }

    static void Main(string[] args)
    {
        RecursionDetector();
        Console.WriteLine();
        Console.ReadLine();
    }

    static void RecursionDetector()
    {
        // First decompile all methods in the assembly:
        Dictionary<MethodBase, MethodBase[]> calling = new Dictionary<MethodBase, MethodBase[]>();
        var assembly = typeof(StackOverflowDetector).Assembly;

        foreach (var type in assembly.GetTypes())
        {
            foreach (var member in type.GetMembers(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Instance).OfType<MethodBase>())
            {
                var body = member.GetMethodBody();
                if (body!=null)
                {
                    var bytes = body.GetILAsByteArray();
                    if (bytes != null)
                    {
                        // Store all the calls of this method:
                        var calls = Decompiler.Decompile(member, bytes);
                        calling[member] = calls;
                    }
                }
            }
        }

        // Check every method:
        foreach (var method in calling.Keys)
        {
            // If method A -> ... -> method A, we have a possible infinite recursion
            CheckRecursion(method, calling, new HashSet<MethodBase>());
        }
    }

现在，方法循环包含递归这一事实绝不保证会发生堆栈溢出 - 它只是堆栈溢出异常最有可能的先决条件。 简而言之，这意味着此代码将确定可能发生堆栈溢出的代码片段，这将大大缩小大多数代码的范围。

其他方法

您还可以尝试一些我未在此处描述的其他方法。

1. 通过托管 CLR 进程并处理它来处理堆栈溢出。 请注意，您仍然无法“抓住”它。
2. 更改所有 IL 代码，构建另一个 DLL，添加对递归的检查。 是的，这很有可能（我过去已经实现过:-)； 这很困难并且需要大量代码才能正确完成。
3. 使用 .NET 分析 API 捕获所有方法调用并使用它来找出堆栈溢出。 例如，您可以实施检查，如果您在调用树中遇到相同的方法 X 次，则发出信号。 有一个项目 clrprofiler 可以让您抢占先机。

Answer 3

我建议围绕 XmlWriter 对象创建一个包装器，这样它就会计算对 WriteStartElement/WriteEndElement 的调用数量，如果将标签数量限制为某个数字（fe 100），您将能够抛出不同的异常，例如 -无效操作。

这应该可以解决大多数情况下的问题

public class LimitedDepthXmlWriter : XmlWriter
{
    private readonly XmlWriter _innerWriter;
    private readonly int _maxDepth;
    private int _depth;

    public LimitedDepthXmlWriter(XmlWriter innerWriter): this(innerWriter, 100)
    {
    }

    public LimitedDepthXmlWriter(XmlWriter innerWriter, int maxDepth)
    {
        _maxDepth = maxDepth;
        _innerWriter = innerWriter;
    }

    public override void Close()
    {
        _innerWriter.Close();
    }

    public override void Flush()
    {
        _innerWriter.Flush();
    }

    public override string LookupPrefix(string ns)
    {
        return _innerWriter.LookupPrefix(ns);
    }

    public override void WriteBase64(byte[] buffer, int index, int count)
    {
        _innerWriter.WriteBase64(buffer, index, count);
    }

    public override void WriteCData(string text)
    {
        _innerWriter.WriteCData(text);
    }

    public override void WriteCharEntity(char ch)
    {
        _innerWriter.WriteCharEntity(ch);
    }

    public override void WriteChars(char[] buffer, int index, int count)
    {
        _innerWriter.WriteChars(buffer, index, count);
    }

    public override void WriteComment(string text)
    {
        _innerWriter.WriteComment(text);
    }

    public override void WriteDocType(string name, string pubid, string sysid, string subset)
    {
        _innerWriter.WriteDocType(name, pubid, sysid, subset);
    }

    public override void WriteEndAttribute()
    {
        _innerWriter.WriteEndAttribute();
    }

    public override void WriteEndDocument()
    {
        _innerWriter.WriteEndDocument();
    }

    public override void WriteEndElement()
    {
        _depth--;

        _innerWriter.WriteEndElement();
    }

    public override void WriteEntityRef(string name)
    {
        _innerWriter.WriteEntityRef(name);
    }

    public override void WriteFullEndElement()
    {
        _innerWriter.WriteFullEndElement();
    }

    public override void WriteProcessingInstruction(string name, string text)
    {
        _innerWriter.WriteProcessingInstruction(name, text);
    }

    public override void WriteRaw(string data)
    {
        _innerWriter.WriteRaw(data);
    }

    public override void WriteRaw(char[] buffer, int index, int count)
    {
        _innerWriter.WriteRaw(buffer, index, count);
    }

    public override void WriteStartAttribute(string prefix, string localName, string ns)
    {
        _innerWriter.WriteStartAttribute(prefix, localName, ns);
    }

    public override void WriteStartDocument(bool standalone)
    {
        _innerWriter.WriteStartDocument(standalone);
    }

    public override void WriteStartDocument()
    {
        _innerWriter.WriteStartDocument();
    }

    public override void WriteStartElement(string prefix, string localName, string ns)
    {
        if (_depth++ > _maxDepth) ThrowException();

        _innerWriter.WriteStartElement(prefix, localName, ns);
    }

    public override WriteState WriteState
    {
        get { return _innerWriter.WriteState; }
    }

    public override void WriteString(string text)
    {
        _innerWriter.WriteString(text);
    }

    public override void WriteSurrogateCharEntity(char lowChar, char highChar)
    {
        _innerWriter.WriteSurrogateCharEntity(lowChar, highChar);
    }

    public override void WriteWhitespace(string ws)
    {
        _innerWriter.WriteWhitespace(ws);
    }

    private void ThrowException()
    {
        throw new InvalidOperationException(string.Format("Result xml has more than {0} nested tags. It is possible that xslt transformation contains an endless recursive call.", _maxDepth));
    }
}

Answer 4

这个答案是给@WilliamJockusch 的。

我想知道是否有通用的方法可以追踪
堆栈溢出异常。 换句话说，假设我有无限
在我的代码中的某个地方递归，但我不知道在哪里。 我想要
通过某种比单步执行代码更容易的方式来追踪它
到处都是，直到我看到它发生。 我不在乎有多黑客
这是。 例如，如果有一个模块我可以
激活，甚至可能来自另一个轮询堆栈的线程
深度，如果达到我认为“太高”的水平，就会抱怨。 为了
例如，我可能将“太高”设置为 600 帧，计算出如果
堆栈太深，这一定是一个问题。 是这样的吗
可能的。 另一个例子是记录每 1000 个方法调用
在我的代码中调试输出。 有机会这会得到一些
超额的证据将是相当好的，而且可能不会
输出太严重了。 关键是不能涉及
在发生溢出的地方写一张支票。 因为整个
问题是我不知道那是哪里。 最好是解决方案
不应该取决于我的开发环境是什么样的； IE，
它不应该假设我通过特定的工具集使用 C#（例如
VS）。

听起来您很想听到一些调试技术来捕获此 StackOverflow，所以我想我会分享一些供您尝试。

1. 内存转储。

专业：内存转储是解决堆栈溢出原因的可靠方法。 AC# MVP 和 我一起对一个 SO 进行故障排除，他继续在博客上介绍它 此处。

此方法是追踪问题的最快方法。

此方法不需要您按照日志中看到的步骤来重现问题。

缺点：内存转储非常大，您必须附加 AdPlus/procdump 进程。

2.面向方面的编程。

专业人士：这可能是您实现从任何方法检查调用堆栈大小的代码的最简单方法，而无需在应用程序的每个方法中编写代码。 有很多 AOP 框架< /a> 允许您在调用之前和之后进行拦截。

会告诉你导致堆栈溢出的方法。

允许您在应用程序中所有方法的入口和出口处检查StackTrace().FrameCount。

缺点：它会对性能产生影响 - 每个方法的钩子都嵌入到 IL 中，您无法真正“停用”它。

这在某种程度上取决于您的开发环境工具集。

3. 记录用户活动。

一周前，我试图找出几个难以重现的问题。 我发布了此 QA 用户活动日志记录、遥测（和变量）在全局异常处理程序中） 。 我得出的结论是一个非常简单的用户操作记录器，用于了解当发生任何未处理的异常时如何在调试器中重现问题。

专业版：您可以随意打开或关闭它（即订阅事件）。

跟踪用户操作不需要拦截每个方法。

您可以计算订阅的事件方法的数量，比 AOP 简单得多。

日志文件相对较小，重点关注重现问题所需执行的操作。

它可以帮助您了解用户如何使用您的应用程序。

缺点：不适合 Windows 服务，而且我确信对于 Web 应用程序有更好的工具。

不一定告诉您导致堆栈溢出的方法。

需要您手动逐步查看日志以重现问题，而不是内存转储，您可以在内存转储中立即获取并调试它。

 

---

也许您可以尝试我上面提到的所有技术以及 @atlaste 发布的一些技术，并告诉我们您发现哪一个是在 PROD 环境等中运行最简单/最快/最脏/最可接受的技术。

不管怎样，祝你好运，找到这个SO。

Answer 5

如果您的应用程序依赖于 3d 方代码（在 Xsl 脚本中），那么您必须首先决定是否要防御其中的错误。
如果你真的想防御，那么我认为你应该在单独的应用程序域中执行容易出现外部错误的逻辑。
捕获 StackOverflowException 并不好。

另请检查这个问题。

Answer 6

在 .NET 4.0 中，您可以将 System.Runtime.ExceptionServices 中的 HandleProcessCorruptedStateExceptions 属性添加到包含 try/catch 块的方法中。 这真的有效！ 也许不推荐但有效。

using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Runtime.ExceptionServices;

namespace ExceptionCatching
{
    public class Test
    {
        public void StackOverflow()
        {
            StackOverflow();
        }

        public void CustomException()
        {
            throw new Exception();
        }

        public unsafe void AccessViolation()
        {
            byte b = *(byte*)(8762765876);
        }
    }

    class Program
    {
        [HandleProcessCorruptedStateExceptions]
        static void Main(string[] args)
        {
            Test test = new Test();
            try {
                //test.StackOverflow();
                test.AccessViolation();
                //test.CustomException();
            }
            catch
            {
                Console.WriteLine("Caught.");
            }

            Console.WriteLine("End of program");

        }

    }      
}

Answer 7

我今天有一个 stackoverflow，我读了你的一些帖子，并决定帮助垃圾收集器。

我曾经有一个近乎无限的循环，如下所示：

    class Foo
    {
        public Foo()
        {
            Go();
        }

        public void Go()
        {
            for (float i = float.MinValue; i < float.MaxValue; i+= 0.000000000000001f)
            {
                byte[] b = new byte[1]; // Causes stackoverflow
            }
        }
    }

相反，让资源超出范围，如下所示：

class Foo
{
    public Foo()
    {
        GoHelper();
    }

    public void GoHelper()
    {
        for (float i = float.MinValue; i < float.MaxValue; i+= 0.000000000000001f)
        {
            Go();
        }
    }

    public void Go()
    {
        byte[] b = new byte[1]; // Will get cleaned by GC
    }   // right now
}

它对我有用，希望它对某人有帮助。

Answer 8

@WilliamJockusch，如果我正确理解你的担忧，那么（从数学的角度来看）不可能总是识别无限递归，因为这意味着解决停止问题。 要解决这个问题，您需要一个超级递归算法（例如试错谓词）或可以超级计算（以下部分 - 可作为预览 - 这本书）。

从实际的角度来看，您必须知道：

• 在给定时间还剩下多少堆栈内存
• 在给定时间您的递归方法需要多少堆栈内存来输出特定输出。

请记住，对于当前的机器，由于多任务处理，这些数据非常可变，而且我还没有听说过可以执行该任务的软件。

如果有不清楚的地方请告诉我。

Answer 9

从表面上看，除了启动另一个进程之外，似乎没有任何方法可以处理 StackOverflowException。 在其他人询问之前，我尝试使用 AppDomain，但这不起作用：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Text;
using System.Threading;

namespace StackOverflowExceptionAppDomainTest
{
    class Program
    {
        static void recrusiveAlgorithm()
        {
            recrusiveAlgorithm();
        }
        static void Main(string[] args)
        {
            if(args.Length>0&&args[0]=="--child")
            {
                recrusiveAlgorithm();
            }
            else
            {
                var domain = AppDomain.CreateDomain("Child domain to test StackOverflowException in.");
                domain.ExecuteAssembly(Assembly.GetEntryAssembly().CodeBase, new[] { "--child" });
                domain.UnhandledException += (object sender, UnhandledExceptionEventArgs e) =>
                {
                    Console.WriteLine("Detected unhandled exception: " + e.ExceptionObject.ToString());
                };
                while (true)
                {
                    Console.WriteLine("*");
                    Thread.Sleep(1000);
                }
            }
        }
    }
}

但是，如果您最终使用单独进程解决方案，我建议使用 Process.Exited code> 和 Process.StandardOutput 并自行处理错误，以便为用户提供更好的体验。

Answer 10

您可以每隔几次调用 Environment.StackTrace 读取此属性，如果堆栈跟踪超出您预设的特定阈值，您可以返回该函数。

您还应该尝试用循环替换一些递归函数。