调试在客户机器上生成的核心文件-IT科技

调试在客户机器上生成的核心文件

2024-10-09 09:11:00

admin

原创

222

摘要：问题描述：我们通过在客户的机器上运行我们的软件来获取核心文件。不幸的是，由于我们一直使用 -O2 进行编译而不使用调试符号，这导致我们无法弄清楚它崩溃的原因，我们修改了构建，现在它们一起生成 -g 和 -O2。然后我们建议客户运行 -g 二进制文件，这样调试起来就更容易了。我有几个问题：如果核心文件是从我们在...

问题描述：

我们通过在客户的机器上运行我们的软件来获取核心文件。不幸的是，由于我们一直使用 -O2 进行编译而不使用调试符号，这导致我们无法弄清楚它崩溃的原因，我们修改了构建，现在它们一起生成 -g 和 -O2。然后我们建议客户运行 -g 二进制文件，这样调试起来就更容易了。

我有几个问题：

如果核心文件是从我们在 Dev 中运行的 Linux 发行版以外的发行版生成的，会发生什么情况？堆栈跟踪是否有意义？
有没有关于 Linux 或 Solaris 调试的好书？以示例为导向的书会很棒。我正在寻找现实生活中的例子来弄清楚程序崩溃的原因以及作者如何找到解决方案。一些更中级到高级水平的书会很好，因为我已经这样做了一段时间了。一些汇编也很好。

下面是一个崩溃示例，需要我们告诉客户获取二进制文件的 -g 版本：

Program terminated with signal 11, Segmentation fault.
#0  0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x00454ff1 in select () from /lib/libc.so.6
...
&lt;omitted frames>

理想情况下，我想解决并找出应用程序崩溃的确切原因 - 我怀疑是内存损坏，但我不是 100％确定。

严格禁止远程调试。

谢谢

解决方案 1：

如果核心文件是从我们在 Dev 中运行的 Linux 发行版以外的发行版生成的，会发生什么情况？堆栈跟踪是否有意义？

如果可执行文件是动态链接的（就像您的一样），那么 GDB 生成的堆栈（很可能）将没有意义。

原因：GDB 知道您的可执行文件因libc.so.6在地址处调用某些内容而崩溃0x00454ff1，但它不知道该地址处的代码是什么。因此，它会查看您的副本libc.so.6并发现这是在中select，因此它会打印该内容。

但是，客户副本0x00454ff1中也包含该地址的可能性很小。最有可能的是，客户在该地址上执行了其他操作。libc.so.6`abort`

您可以使用disas select，并观察是否0x00454ff1位于指令中间，或者前一个指令不是CALL。如果其中任何一个成立，您的堆栈跟踪就毫无意义。

不过，您可以自行解决：您只需从客户系统获取列出的所有库的副本即可(gdb) info shared。让客户使用例如

cd /
tar cvzf to-you.tar.gz lib/libc.so.6 lib/ld-linux.so.2 ...

然后，在您的系统上：

mkdir /tmp/from-customer
tar xzf to-you.tar.gz -C /tmp/from-customer
gdb /path/to/binary
(gdb) set solib-absolute-prefix /tmp/from-customer
(gdb) core core  # Note: very important to set solib-... before loading core
(gdb) where      # Get meaningful stack trace!

然后，我们建议客户运行 -g 二进制文件，以便更容易调试。

一个更好的方法是：

建立-g -O2 -o myexe.dbg
strip -g myexe.dbg -o myexe
分发给myexe顾客
当客户收到时core，使用它myexe.dbg来调试它

您将拥有完整的符号信息（文件/行、局部变量），而无需向客户发送特殊的二进制文件，也不会透露太多有关您的来源的详细信息。

解决方案 2：

您确实可以从崩溃转储中获得有用的信息，即使是从优化编译中获得的信息（尽管从技术上讲，这被称为“非常麻烦”）。-g编译确实更好，是的，即使发生转储的机器是另一个发行版，您也可以这样做。基本上，有一个警告，所有重要信息都包含在可执行文件中，并最终出现在转储中。

当您将核心文件与可执行文件匹配时，调试器将能够告诉您崩溃发生的位置并向您显示堆栈。这本身应该会很有帮助。您还应该尽可能多地了解它发生的情况——他们能可靠地重现它吗？如果可以，你能重现它吗？

现在，这里有一个警告：“一切都在那里”的概念在共享对象文件、.so文件方面不成立。如果由于这些问题而失败，您将无法获得所需的符号表；您可能只能看到.so它发生在哪个库中。

关于调试的书籍有很多，但是我想不出一本可以推荐。

解决方案 3：

从我的问题中复制解决方案，该解决方案被认为是重复的。

set solib-absolute-prefix从接受的解决方案对我没有帮助。set sysroot绝对有必要让 gdb 加载本地提供的库。以下是我用来打开核心转储的命令列表：

# note: all the .so files obtained from user machine must be put into local directory.
#
# most importantly, the following files are necessary:
#   1. libthread_db.so.1 and libpthread.so.0: required for thread debugging.
#   2. other .so files are required if they occur in call stack.
#
# these files must also be renamed exactly as the symlinks
# i.e. libpthread-2.28.so should be renamed to libpthread.so.0

# load executable file
file ./thedarkmod.x64

# force gdb to forget about local system!
# load all .so files using local directory as root
set sysroot .

# drop dump-recorded paths to .so files
# i.e. load ./libpthread.so.0 instead of ./lib/x86_64-linux-gnu/libpthread.so.0
set solib-search-path .
# disable damn security protection
set auto-load safe-path /

# load core dump file
core core.6487

# print stacktrace
bt