使用核心转储在Linux中进行debugging

在使用GDBdebugging核心转储时,什么是“最佳实践”?

目前,我面临一个问题:

  • 我的应用程序的发行版本编译时没有“-g”编译器标志。
  • 我的应用程序的debugging版本(用'-g'编译)被归档(连同源代码和发行版本的副本)。

最近,当用户给我一个核心转储,我试着用它debugging

gdb --core=./core.pid ./my_app_debug-bin 

核心是由my_app_release-bin创build的。 核心文件和二进制文件之间似乎有某种不匹配的地方。

另一方面,如果我尝试

 gdb --core=./core.pid ./my_app_release-bin 

核心匹配,但我无法获得源代码行号(虽然我得到函数名称)。

这是练习吗? 因为我觉得我在这里错过了一些东西。

Solutions Collecting From Web of "使用核心转储在Linux中进行debugging"

这听起来像你的发行版和调试版本之间还有其他区别,那么简单地说-g标志的缺失/存在。 假设情况是这样的,现在你不能做任何事情,但你可以调整你的构建来更好地处理这个问题:

这是我们在工作地点所做的。

  1. 构建发行版本时包含-g标志。
  2. 存档该版本。
  3. 在运送给客户之前,在二进制文件上运行strip --strip-unneeded

现在,当我们发生崩溃时,我们可以使用带有符号的存档版本来进行调试。

有一点要注意的是,如果你的发行版本包含优化,即使使用符号,调试也可能很困难。 例如,即使调试器会说你在第N行崩溃,优化器也可以对你的代码重新排序,但是你不能假定代码实际上是在第N-1行执行的。

你需要做一些额外的事情来创建带有剥离的调试信息的二进制文件,然后你可以从核心进行调试。 最好的描述,我可以找到这里

不,你不会错过任何事情。 调试和发布只是不同的二进制文件,所以发行版的核心文件与调试二进制文件不匹配。 您必须查看机器代码才能从发行版核心转储中获取某些内容。

你可能不得不问你的用户如何发生崩溃,并收集额外的日志信息或任何你的应用程序产生的。