【问题标题】:gdb corefile not see function parametersgdb corefile 看不到函数参数
【发布时间】:2017-09-12 11:13:49
【问题描述】:

我的应用程序由于未捕获的异常而崩溃(我的 c++ 代码在某些情况下抛出未捕获的异常)。我正在尝试 gdb 核心文件。二进制库是“非条带化”的。堆栈跟踪显示了引发未捕获异常的函数(我的代码),但是当我尝试打印函数参数时,我总是得到“当前上下文中没有符号 xxx”。 info args 还返回“没有可用的符号表信息”。

谁能解释为什么?是否由于未捕获的异常展开/破坏堆栈?

谢谢, 弗兰克

【问题讨论】:

  • 核心转储不一定包含所有符号。这可能是由于缺少库或非调试构建的库,甚至是编译器优化。
  • 另外,在提出新问题之前,您应该尝试先发送search stack overflow

标签: c++ exception gdb coredump stack-frame


【解决方案1】:

您的二进制文件缺少调试信息。

如果您使用 gcc 构建它,并且想要调试您已经拥有的 core(如果难以重现崩溃),您可能可以通过以下方式从中恢复使用完全相同相同的源代码和命令行重建二进制文件,添加-g 以编译和链接命令。 (注意:您必须使用相同的编译行;将 -O2 替换为 -g 是不行的。)

如果崩溃不难重现,只需使用-g -O0 重新构建二进制文件,在 GDB 下运行它,然后享受“轻松”调试。

二进制库是“非条带化”的。

这并不意味着你认为它意味着什么。不剥离意味着符号表仍然存在于二进制文件中。

GDB 会读取这个符号表,并用它把地址范围映射到函数名。

但要恢复局部变量和参数的名称和值,您必须使用调试信息进行编译(这是-g 标志对大多数编译器所做的)。

【讨论】:

  • 是否也应该降低优化标志?
  • @dlmeetei 如果您想分析已经存在的core 文件,则不要。
  • 但我们要求重新编译
  • @dlmeetei 是的。所以?使用exact 相同的源代码和命令行重新构建二进制文件,并添加-g经常 允许分析由非调试二进制文件生成的core。这就是我回答的重点
  • 知道了。使用 -g 编译时,我通常也会降低优化标志
猜你喜欢
  • 1970-01-01
  • 2015-07-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-11-14
  • 1970-01-01
相关资源
最近更新 更多