c# - 堆栈跟踪如何指向错误的行( “return”语句)-关闭40行

Question

我现在两次看到从Production ASP.NET MVC 4 Web应用程序记录的NullReferenceException-并在错误的行上记录了代码。一两行没错(就像您遇到的PDB不匹配一样)，但整个 Controller Action 的长度却错了。例子:

public ActionResult Index()
{
    var someObject = GetObjectFromService();
    if (someObject.SomeProperty == "X") { // NullReferenceException here if someObject == null
        // do something
    }

    // about 40 more lines of code

    return View();    // Stack trace shows NullReferenceException here
}

对于同一 Controller 上的 Action ，已发生两次。第二种情况已登录

// someObject is known non-null because of earlier dereferences
return someObject.OtherProperty
    ? RedirecToAction("ViewName", "ControllerName")
    : RedirectToAction("OtherView", "OtherController");

这非常令人不安。一旦知道 NullReferenceException出现在哪一行，它就很容易修复。如果异常可能发生在 Controller Action 中的任何地方，则并不是那么容易!
有没有人在ASP.NET MVC或其他地方看到过类似的东西？我愿意相信这是Release版本和Debug版本之间的区别，但是仍然相差40行吗？

编辑:
需要说明的是:我是“ What is a NullReferenceException and how do I fix it?”的原始作者。我知道 NullReferenceException是什么。这个问题是关于为什么堆栈跟踪可能会如此遥远。我看到了由于PDB不匹配而导致堆栈跟踪偏离一两行的情况。我见过没有PDB的情况，所以您没有行号。但是我从未见过堆栈跟踪偏离32行的情况。
编辑2:
请注意，这是在同一 Controller 中发生两个单独的 Controller Action 时发生的。他们的代码彼此完全不同。实际上，在第一种情况下， NullReferenceException甚至没有在条件条件下发生-它更像是这样:

SomeMethod(someObject.SomeProperty);

有可能在优化过程中对代码进行了重新组织，以使实际的 NullReferenceException更加接近 return，而PDB实际上仅差了几行。但是，我看不到有机会重新安排方法调用，而这将导致代码移动32行。实际上，我只是看了反编译的源代码，并且似乎没有重新排列。
这两种情况的共同点是:

它们出现在同一 Controller 中(到目前为止)

在这两种情况下，堆栈跟踪均指向return语句，并且在两种情况下，NullReferenceException都距return语句30行或更多行。

编辑3:
我只是做了一个实验-我只是使用已部署到生产服务器的“生产”构建配置来重建解决方案。我在本地IIS上运行了该解决方案，而完全没有更改IIS配置。
堆栈跟踪显示正确的行号。
编辑4:
我不知道这是否相关，但是导致 NullReferenceException的情况与此“错误的行号”问题本身一样不寻常。我们似乎无缘无故丢失 session 状态(没有重新启动或进行任何操作)。不太奇怪奇怪的是，发生这种情况时，我们的Session_Start应该重定向到登录页面。重现 session 丢失的任何尝试都会导致重定向到登录页面。随后，使用浏览器的“后退”按钮或手动输入上一个URL即可直接返回登录页面，而无需点击相关的 Controller 。
因此，也许两个怪异的问题确实是一个非常怪异的问题。
编辑5:
我能够获取.PDB文件，并使用 dia2dump进行查看。我认为PDB可能被搞砸了，该方法只有72行。事实并非如此。所有行号都存在于PDB中。
编辑6:
作为记录，这只是在第三个 Controller 中再次发生。堆栈跟踪直接指向方法的return语句。这个return语句就是 return model;。我认为没有任何方法可以导致 NullReferenceException。
编辑6a:
实际上，我只是更仔细地查看了日志，发现了一些不是 NullReferenceException的异常，它们仍然在 return语句中具有堆栈跟踪点。这两种情况都是在从 Controller Action 调用的方法中，而不是直接在 Action 方法本身中。其中之一是显式抛出的 InvalidOperationException，一个是简单的 FormatException。

到现在为止，我还没有想到以下几个事实:

global.asax中的Application_Error是导致记录这些异常的原因。它使用Server.GetLastError()拾取异常。

日志记录机制分别记录消息和堆栈跟踪(而不是记录ex.ToString()，这是我的建议)。特别是，我一直在询问的堆栈跟踪来自ex.StackTrace。

FormatException由System.DateTime.Parse引发，从System.Convert.ToDate调用，从我们的代码调用。指向我们的代码的堆栈跟踪行是指向“return model;”的行。

Answer 1

我曾经在的生产代码中看到过这种行为。尽管细节有些模糊(大约在2年前，虽然我可以找到电子邮件，但我再也无法访问代码了，也无法访问转储等)。

仅供引用，这就是我写给团队的内容(大邮件中的很小部分)-

// Code at TeamProvider.cs:line 34
Team securedTeam = TeamProvider.GetTeamByPath(teamPath); // Static method call.

“在这里不可能发生空引用异常。”

后来，经过更多的跳水潜水

“发现 -

DBI中发生了此问题，因为它没有root/BRH团队。 UI无法正常处理CLib返回的null，因此无法处理异常。

UI上显示的堆栈跟踪具有误导性，这是由于Jitter和CPU可以优化/重新排序指令的事实，导致堆栈跟踪处于“说谎”状态。

深入研究流程转储发现了问题所在，并且已经确认DBI确实没有上述团队。”

我认为，此处要注意的是上面的粗体语句，与与您的分析和声明进行对比-

“我只是看了反编译的源代码，似乎没有重新排列。”，或者

“在我的本地计算机上运行的生产版本显示正确的行号。”

这个想法是优化可以在不同的级别上进行..在编译时完成的只是其中一些。如今，尤其是在使用.Net这样的托管环境时，实际上在发出IL时进行的优化相对较少(为什么当发出的中级语言代码将被进一步转换时，针对10种不同.Net语言的10个编译器应尝试进行相同的优化集(通过ngen或Jitter)转换为机器代码。

因此，只能通过查看生产机器的转储中的jited 机器代码(也称为程序集)来确认所观察到的结果。

我可以看到的一个问题是-为什么对于相同的构建，与您的计算机相比，抖动会在生产计算机上发出不同的代码？

答案-我不知道。我不是Jit专家，但我确实相信它可以……因为如上所述，。与5-10年前使用的技术相比，如今这些东西要复杂得多。谁知道，所有因素是什么？例如“内存，CPU数量，CPU负载，32位与64位，Numa与Non-Numa，方法执行的次数，方法的大小”，谁称呼它？ ，在进行这些优化时会查看它的名称，调用次数，内存位置的访问模式等。

就您的情况而言，到目前为止，只有您可以重现它，并且只有您可以访问已注册的文件
生产中的代码。因此，(如果我可以这样说:)，这是任何人都可以想到的最佳答案。

编辑:
一台机器上的抖动与另一台机器上的抖动之间的重要区别也可以是抖动本身的版本。我可以想象，随着针对.net框架发布了多个补丁和KB，谁知道即使较小的版本也可能存在优化行为抖动的差异。

换句话说，不足以假设两台机器具有相同的框架主版本(假设说.Net 4.5 SP1)，不足。生产中可能没有每天发布的补丁，但是您的开发人员/私有(private)计算机可能上周二发布了补丁。

编辑2 :概念证明-即，抖动优化可能导致说谎的堆栈跟踪。

自己运行以下代码，Release构建，x64，上的 优化，所有TRACE和DEBUG将禁用，Visual Studio Hosting Process将禁用。从Visual Studio编译，但从资源管理器运行。 并尝试猜测堆栈跟踪的哪一行会告诉您异常所在？

class Program
{
    static void Main(string[] args)
    {
        string bar = ReturnMeNull();

        for (int i = 0; i < 100; i++)
        {
            Console.WriteLine(i);
        }

        for (int i = 0; i < bar.Length; i++)
        {
            Console.WriteLine(i);
        }

        Console.ReadLine();

        return;
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static string ReturnMeNull()
    {
        return null;
    }
}

不幸的是，经过几次尝试，我仍然无法重现您所看到的确切问题(即return语句错误)，因为只有您才能访问确切的代码以及它可能具有的任何特定代码模式。还是再次，这是其他一些抖动优化，尚未记录，因此很难猜测。