我想阻止或处理StackOverflowException我从正在编写的XslCompiledTransform.Transform方法调用中得到的。Xsl Editor问题似乎是用户可以编写一个Xsl script无限递归的，它只是在调用该Transform方法时崩溃了。（也就是说，问题不仅仅是典型的程序错误，这通常是导致此类异常的原因。）
有没有办法检测和/或限制允许的递归次数？或者有什么其他想法可以防止这段代码对我产生影响？
John
问问题
155279 次
10 回答
71
来自微软：
从 .NET Framework 2.0 版开始，StackOverflowException 对象无法被 try-catch 块捕获，并且默认情况下会终止相应的进程。因此，建议用户编写代码来检测和防止堆栈溢出。例如，如果您的应用程序依赖于递归，请使用计数器或状态条件来终止递归循环。
我假设异常发生在内部 .NET 方法中，而不是在您的代码中。
你可以做几件事。
- 编写代码检查 xsl 的无限递归，并在应用转换之前通知用户 (Ugh)。
- 将 XslTransform 代码加载到单独的进程中（Hacky，但工作量较少）。
您可以使用 Process 类加载将应用转换的程序集到一个单独的进程中，并在失败时提醒用户失败，而不会终止您的主应用程序。
编辑：我刚刚测试过，这是怎么做的：
主要流程：
// 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");
应用转换过程：
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);
}
}
}
于 2008-10-15T22:56:17.797 回答
26
注意@WilliamJockusch 的赏金问题和原始问题不同。
这个答案是关于第三方库的一般情况下的 StackOverflow 以及你可以/不能用它们做什么。如果您正在寻找 XslTransform 的特殊情况，请参阅接受的答案。
堆栈溢出的发生是因为堆栈上的数据超过了某个限制（以字节为单位）。可以在此处找到有关此检测工作原理的详细信息。
我想知道是否有一种通用的方法来追踪 StackOverflowExceptions。换句话说，假设我的代码中某处有无限递归，但我不知道在哪里。我想通过某种方式来追踪它，这比在整个地方单步执行代码更容易，直到我看到它发生。我不在乎它有多骇人听闻。
正如我在链接中提到的，从静态代码分析中检测堆栈溢出需要解决无法确定的停止问题。既然我们已经确定没有灵丹妙药，我可以向您展示一些我认为有助于追查问题的技巧。
我认为这个问题可以用不同的方式来解释，因为我有点无聊:-)，我会把它分解成不同的变体。
在测试环境中检测堆栈溢出
基本上这里的问题是您有一个（有限的）测试环境，并且想要在（扩展的）生产环境中检测堆栈溢出。
我没有检测 SO 本身，而是利用可以设置堆栈深度的事实来解决这个问题。调试器将为您提供所需的所有信息。大多数语言允许您指定堆栈大小或最大递归深度。
基本上，我尝试通过使堆栈深度尽可能小来强制执行 SO。如果它没有溢出，我总是可以为生产环境让它更大（=在这种情况下：更安全）。当您遇到堆栈溢出时，您可以手动确定它是否是“有效”的。
为此，请将堆栈大小（在我们的示例中：一个小值）传递给 Thread 参数，然后看看会发生什么。.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>());
}
}
现在，方法循环包含递归这一事实决不能保证会发生堆栈溢出 - 它只是堆栈溢出异常最可能的前提条件。简而言之，这意味着该代码将确定可能发生堆栈溢出的代码片段，这将大大缩小大多数代码的范围。
还有其他方法
您可以尝试其他一些我没有在这里描述的方法。
- 通过托管 CLR 进程并对其进行处理来处理堆栈溢出。请注意，您仍然无法“抓住”它。
- 更改所有 IL 代码，构建另一个 DLL，添加递归检查。是的，这很有可能（我过去已经实现了：-）；这很困难，并且需要大量代码才能使其正确。
- 使用 .NET 分析 API 来捕获所有方法调用并使用它来确定堆栈溢出。例如，您可以实施检查，如果您在调用树中遇到 X 次相同的方法，您会发出信号。有一个项目clrprofiler可以让您抢先一步。
于 2015-06-06T09:13:31.960 回答
9
我建议围绕 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));
}
}
于 2010-01-22T13:00:20.573 回答
5
这个答案是给@WilliamJockusch 的。
我想知道是否有一种通用的方法来追踪 StackOverflowExceptions。换句话说，假设我的代码中某处有无限递归，但我不知道在哪里。我想通过某种方式来追踪它，这比在整个地方单步执行代码更容易，直到我看到它发生。我不在乎它有多骇人听闻。例如，如果有一个模块我可以激活，甚至可以从另一个线程激活，它会轮询堆栈深度并抱怨它是否达到我认为“太高”的级别，这将是很棒的。例如，我可能将“太高”设置为 600 帧，认为如果堆栈太深，那一定是个问题。有没有可能。另一个例子是将我的代码中的每 1000 个方法调用记录到调试输出。这将获得一些过低的证据的机会非常好，而且它可能不会太严重地破坏输出。关键是它不能在发生溢出的地方写检查。因为整个问题是我不知道那在哪里。最好解决方案不应该取决于我的开发环境是什么样的；即，它不应该假设我通过特定的工具集（例如VS）使用C#。
听起来你很想听一些调试技术来捕捉这个 StackOverflow，所以我想我会分享一些给你尝试。
1. 内存转储。
专业人士：内存转储是找出堆栈溢出原因的可靠方法。AC# MVP 和我一起对 SO 进行了故障排除，他继续在此处写博客。
这种方法是追查问题的最快方法。
此方法不需要您按照日志中的步骤重现问题。
缺点：内存转储非常大，您必须附加 AdPlus/procdump 进程。
2. 面向方面的编程。
专业人士：这可能是您实现代码的最简单方法，该代码可以从任何方法检查调用堆栈的大小，而无需在应用程序的每个方法中编写代码。有一堆AOP 框架允许您在调用之前和之后进行拦截。
将告诉您导致堆栈溢出的方法。
允许您检查StackTrace().FrameCount应用程序中所有方法的入口和出口。
缺点：它会对性能产生影响——每个方法的钩子都嵌入到 IL 中，你不能真正“取消激活”它。
这在某种程度上取决于您的开发环境工具集。
3. 记录用户活动。
一周前，我试图寻找几个难以重现的问题。我发布了这个 QA User Activity Logging, Telemetry (and Variables in Global Exception Handlers)。我得出的结论是一个非常简单的用户操作记录器，用于查看当发生任何未处理的异常时如何在调试器中重现问题。
专业人士：您可以随意打开或关闭它（即订阅事件）。
跟踪用户操作不需要拦截每个方法。
您可以比使用 AOP 更简单地计算订阅方法的事件数量。
日志文件相对较小，主要关注重现问题所需执行的操作。
它可以帮助您了解用户如何使用您的应用程序。
缺点：不适合 Windows 服务，我敢肯定有更好的类似这样的工具用于 web 应用程序。
不一定会告诉您导致堆栈溢出的方法。
要求您逐步通过日志手动重现问题，而不是通过内存转储，您可以在其中立即获取并调试它。
也许您可以尝试我上面提到的所有技术以及@atlaste 发布的一些技术，并告诉我们您发现哪些是在 PROD 环境/等中运行最简单/最快/最脏/最可接受的技术。
无论如何，祝你好运追踪这个 SO。
于 2015-06-06T10:22:50.053 回答
3
如果您的应用程序依赖于 3d 方代码（在 Xsl 脚本中），那么您必须首先决定是否要防御其中的错误。如果您真的想捍卫，那么我认为您应该在单独的 AppDomain 中执行容易出现外部错误的逻辑。捕获 StackOverflowException 并不好。
还要检查这个问题。
于 2010-09-01T14:40:33.497 回答
2
在 .NET 4.0 中，您可以将HandleProcessCorruptedStateExceptionsSystem.Runtime.ExceptionServices 中的属性添加到包含 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");
}
}
}
于 2010-08-25T09:54:02.593 回答
2
我今天有一个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
}
它对我有用，希望对某人有所帮助。
于 2013-07-09T16:22:20.217 回答
1
@WilliamJockusch，如果我正确理解了您的担忧，那么（从数学的角度来看）不可能总是识别出无限递归，因为这意味着要解决Halting problem。为了解决这个问题，你需要一个超级递归算法（例如试错谓词）或一台可以进行超计算的机器（一个例子在本书的下一节中解释- 可作为预览提供）。
从实际的角度来看，您必须知道：
- 在给定时间您还剩下多少堆栈内存
- 在给定时间，您的递归方法需要多少堆栈内存才能用于特定输出。
请记住，对于当前的机器，由于多任务处理，这些数据非常易变，我还没有听说过可以完成这项任务的软件。
如果有不清楚的地方，请告诉我。
于 2015-06-12T08:30:06.460 回答
0
从表面上看，除了启动另一个进程之外，似乎没有任何方法可以处理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并Process.StandardOutput处理错误，以便为您的用户提供更好的体验。
于 2015-06-11T13:47:43.830 回答
-2
您可以每隔几次调用就读取此属性Environment.StackTrace，如果堆栈跟踪超出了您预设的特定阈值，则可以返回该函数。
您还应该尝试用循环替换一些递归函数。
于 2012-12-27T18:18:10.683 回答