问题描述
我们从客户的盒子中获取运行我们的软件的核心文件。不幸的是，因为我们一直使用-O2 编译没有调试符号，这导致了我们无法弄清楚为什么崩溃的情况，我们已经修改了构建，现在他们生成-g和 - O2在一起然后我们建议客户运行一个-g二进制文件，以便调试变得更容易。
We get core files from running our software on a Customer's box. Unfortunately because we've always compiled with -O2 without debugging symbols this has lead to situations where we could not figure out why it was crashing, we've modified the builds so now they generate -g and -O2 together. We then advice the Customer to run a -g binary so it becomes easier to debug.
我有几个问题：
- 当从Linux发行版生成核心文件，而不是我们在Dev中运行的文件时，会发生什么？堆栈跟踪是否也有意义？
- 在Linux或Solaris上是否有调试的好书？一些面向事例将是巨大的。我正在寻找一个真实的例子来弄清楚为什么一个例程崩溃，以及作者如何到达解决方案。在中级到高级之间的事情会更好一些，因为我已经做了一段时间了。一些装配也会很好。
这是一个崩溃的例子，要求我们告诉客户获得-g版。的二进制：
Here's an example of a crash that requires us to tell the Customer to get a -g ver. of the binary:
c $ c> libc.so.6 的副本，并发现这是在中选择，所以打印出来。The reason: GDB knows that your executable crashed by calling something in libc.so.6 at address 0x00454ff1, but it doesn't know what code was at that address. So it looks into your copy of libc.so.6 and discovers that this is in select, so it prints that.
但是，您的中也可以选择 0x00454ff1 客户副本 libc.so.6 相当小。很可能客户在该地址处有其他一些程序，也许 abort 。
But the chances that 0x00454ff1 is also in select in your customers copy of libc.so.6 are quite small. Most likely the customer had some other procedure at that address, perhaps abort.
您可以使用 disas选择，并观察 0x00454ff1 是在指令的中间，或者以前的指令不是 CALL 。如果其中任何一个保持，您的堆栈跟踪是无意义的。
You can use disas select, and observe that 0x00454ff1 is either in the middle of instruction, or that the previous instruction is not a CALL. If either of these holds, your stack trace is meaningless.
您可以可以帮助您：只需要获取所有库的副本它们在客户系统的（gdb）信息共享中列出。让客户用他们的方式，例如
You can however help yourself: you just need to get a copy of all libraries that are listed in (gdb) info shared from the customer system. Have the customer tar them up with e.g.
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 -O2 -o myexe.dbg
- cp myexe.dbg myexe
- strip -g myexe
- 当客户获得核心分发给客户
- >，使用 myexe.dbg 进行调试
- build with -g -O2 -o myexe.dbg
- cp myexe.dbg myexe
- strip -g myexe
- distribute myexe to customers
- when a customer gets a core, use myexe.dbg to debug it
符号信息（文件/行，局部变量），而不必向客户发送特殊的二进制文件，而不会透露太多关于您来源的详细信息。
You'll have full symbolic info (file/line, local variables), without having to ship a special binary to the customer, and without revealing too many details about your sources.
这篇关于调试在客户机箱上生成的核心文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！