堆栈跟踪中的行号错误 [英] Wrong line numbers in stack trace

问题描述

在我们的ASP .net网站上，我不断在堆栈异常跟踪中得到错误的行号.我说的是我们的生活环境.似乎有一种模式:堆栈跟踪将始终指向包含该方法的大括号的行.

On our ASP .net website I keep getting wrong line numbers in stack traces of exceptions. I am talking about our live environment. There seems to be a pattern: The stack trace will always point to the line that contains the method's closing curly brackets.

例如:

public class Foo
{
    public void Bar()
    {
        object someObject = null;
        someObject.ToString();
     /*
          arbitrarily more lines of code
     */
     } // this line will be the one that the stack trace points to
}

更多详细信息

• 要清楚:这不仅发生在某些方法上，而且还发生在我们记录的每个异常中.因此，在这里我将排除(JIT)优化，这可能会导致行号看似随机关闭.令我困扰的是，错误的行号似乎始终指向包含方法的右花括号.

  More details

  • To be clear: This does not only happen for some method(s), it happens for every exception that we log. So I would rule out (JIT) optimizations here, that might lead to line numbers being seemingly randomly off. What bothers me is, that the wrong line numbers seem to consistently point to the closing curly brackets of the containing method.

    请注意，在.net 4.6之前，该框架中实际上存在一个错误，因此，如果您针对x64进行编译，则确实会发生这种情况.但是，Microsoft确认此问题已得到解决.为此，还运行了一个最小的示例应用程序，重申了他们的主张.但是由于某种原因，它仍然会在Web服务器上发生.

    Note that before .net 4.6 there actually was a bug in the framework, such that if you compiled targeting x64, exactly this would happen. However, Microsoft confirmed that this has been fixed. Also running a minimal example app for this, reaffirms their claim. But for some reason it still happens on the web servers.

    它使我更加困惑，因为它在我们的测试和开发环境中不会发生.测试系统和实时系统的设置非常相似.唯一的不同是，实时运行的是Windows Server 2012，而在测试系统上，我们仍在使用Windows Server 2008.

    It puzzles me even more that it does not happen in our test and development environments. The test and live systems are pretty similarly set up. The only real difference is that live we are running Windows Server 2012, while on the test system we are still using Windows Server 2008.

    • pdb文件有效(已通过chkmatch测试)
    • 编译时代码优化不是问题
    • 4.6之前的.net中的上述错误无法通过最少的示例进行复制
    • .NET版本完全相同
    • 内部版本来自相同的部署脚本

    任何解决此问题的线索都受到高度赞赏.如果您知道我们可以检查的任何内容，请告诉我.

    Any clues towards solving this problem are highly appreciated. If you know anything that we could check, please let me know.

    推荐答案

    感谢大家的帮助！我们发现 SCOM APM代理在生产中的机器上运行导致我们的应用程序在堆栈跟踪中记录了错误的行号.停用代理后，行号就正确了.

    Thanks everyone for your help! We found out that the SCOM APM agent running on the machines in production caused our application to log wrong line numbers in the stack traces. As soon as we deactivated the agent, the line numbers were correct.

    这篇关于堆栈跟踪中的行号错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！