在Linux中使用核心转储进行调试 [英] Debugging in Linux using core dumps
问题描述
当使用GDB调试核心转储时，最佳做法是什么？
What are the 'best practices' when it comes to debugging core dumps using GDB?
目前，我面临一个问题：
Currently, I am facing a problem:
- 我的应用程序的发行版本没有编译-g编译器标志。
- 我的应用程序的调试版本编译时使用'-g'）归档（与源代码和发布二进制文件的副本一起）。
当用户给我一个核心转储，我试着调试它使用
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
核心是由 my_app_release-bin 。在核心文件和二进制文件之间似乎有某种不匹配。
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
另一方面，如果我尝试
gdb --core=./core.pid ./my_app_release-bin
核心匹配，但我无法获得源代码行号（虽然我得到函数名称）。
the core matches but I am unable to get source code line numbers (although I get the function names).
这是什么练习？因为我觉得我在这里缺少一些东西。
Is this what is practised? Because I feel I am missing something here.
推荐答案
听起来你的发布和调试生成之间还有其他的区别，不存在/存在 -g 标志。假设是这样，现在没有什么可以做的，但你可以调整你的构建来处理这个更好：
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
这里是我们在我的工作地点做。
Here's what we do at my place of work.
- 在建立发布版本时包含
-g标志。
- 存档该版本。
- 在将二进制文件发送给客户之前，运行
strip --strip-unneeded。
- Include the
-gflag when building the release version. - Archive that version.
- run
strip --strip-unneededon the binary before shipping it to customers.
现在，当我们遇到崩溃时，我们可以使用带有符号的归档版本进行调试。
Now, when we get a crash we can use the archived version with symbols to do debugging.
需要注意的一点是，如果你的发布版本包括优化，调试可能很难甚至用符号。例如，优化器可以重新排序你的代码，所以即使调试器会说你在第N行崩溃，你不能假定代码实际执行的行N-1。
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
这篇关于在Linux中使用核心转储进行调试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
