c# - 如何跟踪.NET中StackOverflowException的原因？

运行以下代码时，我得到StackOverflowException:

private void MyButton_Click(object sender, EventArgs e) {
  MyButton_Click_Aux();
}

private static volatile int reportCount;

private static void MyButton_Click_Aux() {
  try { /*remove because stack overflows without*/ }
  finally {
    var myLogData = new ArrayList();
    myLogData.Add(reportCount);
    myLogData.Add("method MyButtonClickAux");
    Log(myLogData);
  }
}

private static void Log(object logData) {
  // my log code is not matter
}

是什么导致StackOverflowException？

最佳答案

我知道如何阻止它的发生

我只是不知道为什么会导致它(至今)。看来您确实在.Net BCL中或更可能在JIT中发现了一个错误。

我只是注释掉了MyButton_Click_Aux方法中的所有行，然后开始将它们逐一引入。

从静态int中删除volatile，您将不再获得StackOverflowException。

现在要研究原因...很明显，与内存屏障有关的问题引起了问题-也许以某种方式迫使MyButton_Click_Aux方法自行调用...

更新

好的，所以其他人发现.Net 3.5不是问题。

我也使用.Nt 4，因此这些注释与此有关:

就像我说的，先去除 volatile ，然后再行之有效。

同样，如果重新打开 volatile 并删除try/final，它也可以工作:

private static void MyButton_Click_Aux()
{
  //try { /*remove because stack overflows without*/ }
  //finally
  //{
    var myLogData = new ArrayList();
    myLogData.Add(reportCount);
    //myLogData.Add("method MyButtonClickAux");
    //Log(myLogData);
  //}
}

我还想知道在try/final时是否与未初始化的reportCount有关。但是，如果将其初始化为零，则没有任何区别。

我现在正在研究IL-尽管可能需要具有一些ASM小伙子的人参与其中...

最终更新
就像我说的那样，这确实需要对JIT输出进行分析才能真正了解正在发生的事情，而我发现分析汇编器很有趣-我觉得这对于Microsoft的某个人来说可能是一件工作，因此此错误实际上可以得到确认和解决!话虽如此-看来情况似乎非常狭窄。

我已经移至发布版本，以摆脱所有IL噪声(噪声等)进行分析。

但是，这对诊断产生了复杂的影响。我以为自己有但是没有-但是现在我知道它是什么了。

我尝试了这段代码:

private static void MyButton_Click_Aux()
{
  try { }
  finally
  {
    var myLogData = new ArrayList();
    Console.WriteLine(reportCount);
    //myLogData.Add("method MyButtonClickAux");
    //Log(myLogData);
  }
}

与int一样易变。它运行无故障。这是IL:

.maxstack 1
L_0000: leave.s L_0015
L_0002: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()
L_0007: pop
L_0008: volatile.
L_000a: ldsfld int32 modreq([mscorlib]System.Runtime.CompilerServices.IsVolatile) WindowsFormsApplication1.Form1::reportCount
L_000f: call void [mscorlib]System.Console::WriteLine(int32)
L_0014: endfinally
L_0015: ret
.try L_0000 to L_0002 finally handler L_0002 to L_0015

然后，我们查看再次获得该错误所需的最少代码:

private static void MyButton_Click_Aux()
{
  try { }
  finally
  {
    var myLogData = new ArrayList();
    myLogData.Add(reportCount);
  }
}

这是IL:

.maxstack 2
.locals init (
    [0] class [mscorlib]System.Collections.ArrayList myLogData)
L_0000: leave.s L_001c
L_0002: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()
L_0007: stloc.0
L_0008: ldloc.0
L_0009: volatile.
L_000b: ldsfld int32 modreq([mscorlib]System.Runtime.CompilerServices.IsVolatile) WindowsFormsApplication1.Form1::reportCount
L_0010: box int32
L_0015: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)
L_001a: pop
L_001b: endfinally
L_001c: ret
.try L_0000 to L_0002 finally handler L_0002 to L_001c

区别？好吧，我发现了两个-volatile int的装箱和一个虚拟调用。因此，我设置了这两个类:

public class DoesNothingBase
{
  public void NonVirtualFooBox(object arg) { }
  public void NonVirtualFooNonBox(int arg) { }

  public virtual void FooBox(object arg) { }
  public virtual void FooNonBox(int arg) { }
}

public class DoesNothing : DoesNothingBase
{
  public override void FooBox(object arg) { }
  public override void FooNonBox(int arg) { }
}

然后尝试使用这四个版本的冒犯方法:

try { }
finally
{
  var doesNothing = new DoesNothing();
  doesNothing.FooNonBox(reportCount);
}

哪个有效。

try { }
finally
{
  var doesNothing = new DoesNothing();
  doesNothing.NonVirtualFooNonBox(reportCount);
}

这也有效。

try { }
finally
{
  var doesNothing = new DoesNothing();
  doesNothing.FooBox(reportCount);
}

糟糕-StackOverflowException。

和:

try { }
finally
{
  var doesNothing = new DoesNothing();
  doesNothing.NonVirtualFooBox(reportCount);
}

再次糟糕! StackOverflowException!

我们可以继续做下去-但我认为问题很明显是由try/catch的finally块内的volatile int装箱引起的...我将代码放入try内，没有问题。我添加了catch子句(并将代码放在其中)，也没有问题。

我猜它也可以应用于其他值类型的装箱。

因此，总而言之-在.Net 4.0中-在调试版本和发行版本中-final块中的volatile int的装箱似乎都会导致JIT生成最终填充堆栈的代码。堆栈跟踪仅显示“外部代码”这一事实也支持这一主张。

甚至有可能无法始终复制它，甚至可能取决于try/finally生成的代码的布局和大小。显然，这与错误的jmp有关，或者与在错误的位置生成了类似的东西，最终在堆栈中重复了一个或多个push命令。坦率地说，实际上是由Box操作引起的想法很有趣!

最终最终更新

如果您查看@Hasty G发现的MS Connect错误(进一步解答)-您会看到该错误以类似的方式出现，但是catch语句中包含一个不稳定的 bool 值。

另外-MS在对其进行修复后将其排队等待修复-但7个月后尚无可用的修复程序。在支持MS Connect之前，我已经记录在案，所以我不再赘述-我认为我不需要!

最终最终最终更新(23/02/2011)

它是固定的-但尚未发布。来自MS团队的MS Connect错误报价: