调试客户包装盒上生成的核心文件

Question

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

我有几个问题：

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

在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

实际上，您可以从崩溃转储中获得有用的信息，甚至可以从优化的编译中获得有用的信息（尽管从技术上来说，这就是所谓的“大麻烦”。）-g编译确实更好，是的，甚至您也可以这样做。当发生转储的机器是另一个发行版时。基本上，只有一个警告，所有重要信息都包含在可执行文件中，并最终在转储中。当您将核心文件与可执行文件进行匹配时，调试器将能够告诉您崩溃发生的位置并向您显示堆栈。这本身应该会有所帮助。您还应该尽可能多地了解它发生的情况-他们可以可靠地复制它吗？如果是这样，您可以复制它吗？现在，这是一个警告：“一切都存在”的概念被分解的地方是共享对象文件，.so文件。如果由于这些问题而失败，那么您将不需要所需的符号表；您可能只能看到.so它发生在什么库中。有很多关于调试的书，但是我想不出我推荐的书。

Answer 2

检查遍历堆栈时看到的局部变量的值？特别是在select（）调用周围。在客户的箱子上执行此操作，只需加载转储并遍历堆栈...另外，还要在DEV和PROD平台上检查FD_SETSIZE的值！