我有我们已经部署到客户网站C应用。 它被编译并运行在HP-UX。 用户报告了崩溃，我们已经获得了核心转储。 到目前为止，我已经无法复制的崩溃房子。
正如你所疑，核心文件/部署的可执行文件是完全没有任何形式的符号组成。 当我在gdb加载它，做一个BT，我得到的最好的是这样的：
(gdb) bt
#0 0xc0199470 in ?? ()
我可以做的文件“串核心”，但我的理解是，我得到的有在可执行文件中的所有字符串，这样看来半不可能有追查什么。
我有可执行文件，这是不幸几个月比发布版本更新的调试版本（使用-g编译）。 如果我试图与该中心启动gdb，我看到这一点：
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 ?? ()
虽然这将是可行的编译调试版本，并在客户的现场部署，然后等待另一个崩溃，那将是一个多种原因比较困难和不可取的。
我很熟悉的代码，并有其中的代码是基于客户的错误报告轰然一个相对不错的主意。
有没有什么办法，我可以搜集从这个核心转储的信息吗？ 通过字符串或另一个调试或什么？ 谢谢。
这种类型的从GDB响应的：
(gdb) bt
#0 0xc0199470 in ?? ()
也有可能发生在堆被缓冲区溢出，返回地址是在内存覆盖砸了，所以程序计数器被设置为一个看似随机的区域的情况。
这是，即使是与相应的符号数据库的构建可导致符号查找错误的方式（或奇怪的看着回溯）之一。 如果你还是收到这个你有符号表后，您的问题可能是您的客户的数据会引起一些问题与您的代码。
为未来：
- 请确保您始终与外部符号数据库建立（这不是一个调试版本 - 这是一个发布版本，但是你单独存放符号表）
- 保持它周围部署版本
对于这样的情况：
你知道一般的区域，所以就看你是对的，去堆栈跟踪，找到汇编代码 - 眼球，看看，如果你认为它的源（这是比较容易，如果你有一些想法是什么源产生这种匹配部件）。 如果它看起来正确的，那么你有你的假设一些验证。 （因为你知道你在通过并宣布）您可能能够通过查看堆栈找出局部变量的值。
在gdb下，“信息寄存器”应在崩溃时与可执行文件并和有关共享库的拆装使用给你足够的执行状态。 我通常使用objdump的拆解，将输出重定向到一个文件，然后打开该文件中我最喜欢的编辑器 - 这是保持笔记事情想通了，非常有用。 此外GDB的“信息目标”和“信息sharedlib”可以成为其中的共享库被加载找出有用的。
与寄存器状态，堆栈内容，并在手拆卸一点点运气沿，它应该是直接的（如果乏味）来重建调用堆栈（除非，当然，在堆栈已经通过缓冲区溢出或类似灾难丢弃...可能需要在这种情况下的占卜板或水晶球。）
您可能还能够与反对的剥离版本的拆卸-g建立新的版本AA拆卸相关。
你有你用来编译旧版本的确切来源（例如，通过标签在源树或类似的东西）？ 也许你可以重新使用，并且可能获得见识到了崩溃发生在哪里？
尝试运行“PMAP”对核心文件（如果HP / UX拥有这个工具）。 这应该在核心文件报告所有模块的起始地址。 有了这个信息，你应该能够把故障位置的地址，并找出什么坠毁库。 飞机坠毁的地址和已知函数库（“纳米”对图书馆应该得到那个）地址之间进一步的地址比较可以帮助您确定坠毁什么功能。
即使你设法在堆栈的顶部识别功能，这是不太可能，这个功能是问题的根源...希望它已经在你的代码实际上崩溃，而不是，比方说，标准C字符串库。 重建堆栈跟踪是在这一点上退而求其次。
这里没有太多的信息。 二进制是stripped.But看着段错误...你应该找地方有将要覆盖一块内存的可能性。
这仅仅是一个建议。 可以有很多问题。
顺便说一句，如果你不能够在您的本地机器上，然后复制数据量的客户可能是一个问题。
我不认为核心文件应该包含符号。 你需要能够建立一个版本的程序是完全一样的 ，你运到你的客户什么，但-g。 如果你带你的调试可执行文件，它应该是相同的出货版本。 只有这样，才能用gdb给你什么有用的东西。
