gdb 调试远程核心转储答案

【问题标题】：gdb debug remote core dumpgdb 调试远程核心转储
【发布时间】：2013-02-22 23:40:40
【问题描述】：

我有一个用C++ 编写的服务器在我无法直接访问的生产环境中崩溃。崩溃生成了一个巨大的核心转储 ~34G，我无法在本地复制。我需要分析核心转储，但不知道如何在不复制的情况下完成。我尝试在目标上运行gdbserver，但它不将核心文件作为参数，并且似乎只适用于从主机调试正在运行的远程应用程序。有没有办法做到这一点？

【问题讨论】：

对于生成该大小转储的程序，您是否已经有一个日志机制来帮助您将问题缩小到应用程序的特定部分？
使用ssh 登录远程机器——如果你有gdbserver 访问权限，我希望你能做大部分事情。
我不能ssh 到远程机器，但可以要求系统管理员为我运行gdbserver 之类的东西，但他无法分析和调试核心文件。我正在考虑一个更永久的解决方案，这种解决方案在未来发生这种情况时也可以使用。而且我们还没有实现适当的日志记录机制:(
@user1444800：您是否考虑过使用 bzip2 或 lrzip 压缩核心转储？
即使我压缩它，我仍然需要解压缩它才能在 gdb 上运行它，我不想在我的本地机器上这样做。

标签： c++ debugging gdb remote-debugging

【解决方案1】：

我需要分析核心转储，但不知道如何在不复制的情况下完成。

你不能。您需要将核心转储放到可以运行 GDB 的位置。

我无法通过 ssh 连接到远程机器，但可以要求系统管理员为我运行 gdbserver 之类的东西，但他无法分析和调试核心文件。

您不需要系统管理员来分析任何内容。您只需要让他运行一系列 GDB 命令，并将输出发送给您。例如

where
thread apply all where
info registers
disas

... 会让您以很长的方式了解问题，并且您的系统管理员将花费不到 5 分钟的时间。

我仍然需要解压缩它才能在 gdb 上运行它，我不想在我的本地机器上这样做。

另外，请与您的经理交谈。您的开发设置不合理。您必须能够在本地分析生产崩溃，这意味着您必须能够使用足够强大的机器。

【讨论】：