不带符号调试核心文件 [英] Debug core file with no symbols

问题描述

我有我们已经部署到客户网站的C应用程序。它被编译并运行在HP-UX。用户报告了崩溃，我们已经获得了核心转储。到目前为止，我已经无法复制的崩溃房子。

I have a C application we have deployed to a customers site. It was compiled and runs on HP-UX. The user has reported a crash and we have obtained a core dump. So far, I've been unable to duplicate the crash in house.

正如你所疑，核心文件/部署的可执行文件是完全没有任何形式的符号组成。当我在gdb中加载它，做一个BT，我得到的最好的是这样的：

As you would suspect, the core file/deployed executable is completely devoid of any sort of symbols. When I load it up in gdb and do a bt, the best I get is this:

(gdb) bt
#0  0xc0199470 in ?? ()

我可以做该文件的'弦核心，但我的理解是，我得到的有可执行所有的字符串，这样看来半不可能有追踪任何东西。

I can do a 'strings core' on the file, but my understanding is that all I get there is all the strings in the executable, so it seems semi-impossible to track down anything there.

我有可执行文件，这是不幸的几个月比发布版本更新的调试版本（使用-g编译）。如果我试图与该中心启动gdb，我看到：

I do have a debug version (compiled with -g) of the executable, which is unfortunately a couple of months newer than the released version. If I try to start gdb with that hub, I see this:

warning: exec file is newer than core file.
Core was generated by `program_name'.
Program terminated with signal 11, Segmentation fault.
__dld_list is not valid according to __dld_flags.

#0  0xc0199470 in ?? ()
(gdb) bt
#0  0xc0199470 in ?? ()

虽然这将是可行的，编译的调试版本，并在客户现场部署它，然后等待另一个碰撞，这将是有许多原因相当困难和不希望的。

While it would be feasible to compile a debug version and deploy it at the customer's site and then wait for another crash, it would be relatively difficult and undesirable for a number of reasons.

我很熟悉的code和有其中code它是基于客户的错误报告轰然一个比较不错的主意。

I am quite familiar with the code and have a relatively good idea of where in code it is crashing based on the customer's bug report.

有什么办法，我可以收集从这个核心转储任何更多的信息？通过字符串或其他调试器或什么？谢谢你。

Is there ANY way I can glean any more information from this core dump? Via strings or another debugger or anything? Thanks.

推荐答案

该类型从gdb的响应：

This type of response from gdb:

(gdb) bt
#0  0xc0199470 in ?? ()

也有可能发生在堆栈是由缓冲区溢出，返回地址是在内存中覆盖被砸的情况下，这样的程序计数器被设置为一个看似随意的区域。

can also happen in the case that the stack was smashed by a buffer overrun, where the return address was overwritten in memory, so the program counter gets set to a seemingly random area.

这是，即使是与相应的符号数据库的构建可导致符号查找错误的方式（或奇怪的看着回溯）之一。如果仍然出现这个，你有符号表后，您的问题可能是您的客户的数据会引起一些问题与code。

This is one of the ways that even a build with a corresponding symbol database can cause a symbol lookup error (or strange looking backtraces). If you still get this after you have the symbol table, your problem is likely that your customer's data is causing some issues with your code.

这篇关于不带符号调试核心文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！