【问题标题】:Stack trace with incorrect line number行号不正确的堆栈跟踪
【发布时间】:2011-02-19 03:34:33
【问题描述】:

为什么堆栈跟踪会显示“第 0 行”,但仅显示堆栈跟踪中的一帧

例如。

...
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
at My.LibraryA.Some.Method():line 16
at My.LibraryB.Some.OtherMethod():line 0
at My.LibraryB.Some.Method():line 22
at My.LibraryA.Some.Method():line 10

背景:

我有一个应用程序因异常而失败,并且正在将堆栈跟踪记录到其日志文件中。构建应用程序时,所有程序集都使用完整的调试信息(项目属性 -> 构建 -> 高级 -> 调试信息 -> 完整)进行编译,因此生成了 PDB 文件。为了帮助我诊断错误的来源,我将 PDB 文件放到了应用程序的 bin 目录中,并重现了异常。每个堆栈帧的所有行号看起来都正确,但显示“第 0 行”作为其源的除外。

【问题讨论】:

  • 编译时是否开启了优化? (请记住,优化开/关和调试信息开/关是正交开关。)如果是这样,那么抖动可能会选择进行内联或其他优化,这可能会导致难以确定原始代码的位置。
  • @Eric:是的。有什么办法可以得到实际的行号吗?
  • 当然。在关闭优化的情况下编译它。
  • 还要注意,如果可以进行尾递归,则允许抖动优化掉调用堆栈帧。许多人似乎不理解的一个重要事实:调用堆栈不会告诉您调用来自哪里。它会告诉您接下来控制将去往何处。通常,您可以通过知道呼叫接下来要去哪里来确定呼叫来自哪里,但是如果抖动可以在不保留有关呼叫来自哪里的信息的情况下确定控制接下来要去哪里,则允许这样做。

标签: c# .net stack-trace line-numbers


【解决方案1】:

这确实是 Eric 建议的内联方法。

我设法在本地重现了原始错误,但仅限于在发布版本中编译时。因为我有 PDB,所以我可以单步执行代码并找出问题所在。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-12-03
    • 2014-03-03
    • 2016-07-03
    • 2012-12-12
    相关资源
    最近更新 更多