c++ - 调试客户机器上生成的核心文件

Question

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

我有几个问题:

1. 如果核心文件是从我们在 Dev 中运行的 Linux 发行版以外的发行版生成的，会发生什么情况？堆栈跟踪是否有意义？
2. 有没有关于在 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
...
<omitted frames>

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

严禁远程调试。

谢谢

Answer 1

What happens when a core file is generated from a Linux distro other than the one we are running in Dev? Is the stack trace even meaningful?

如果可执行文件是动态链接的，就像您的一样，GDB 生成的堆栈将(很可能)不有意义。

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

但是 0x00454ff1 也在您的 customers 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!

We then advice the Customer to run a -g binary so it becomes easier to debug.

一个好得多的方法是:

• 使用-g -O2 -o myexe.dbg构建
• strip -g myexe.dbg -o myexe
• 分发 myexe 给客户
• 当客户拿到core时，使用myexe.dbg调试

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