2

我正在使用 Linux redhat 3，有人能解释一下我如何能够使用 gdb 进行分析，这是在 Linux redhat 5 中生成的核心转储吗？

不是我抱怨:) 但我需要确保这将永远有效......？

编辑：共享库是相同的版本，所以不用担心，它们被放置在一个共享存储中，因此可以从 linux 5 和 linux 3 访问它。

谢谢。

4

5 回答 5

4

您可以尝试以下 GDB 命令打开核心文件

gdb
 (gdb) exec-file <executable address>
 (gdb) set solib-absolute-prefix <path to shared library>
 (gdb) core-file <path to core file>

之所以不能依赖，是因为每个进程都使用了libc或者系统共享库，从Red hat 3到red hat 5肯定会有变化。所以native函数中的所有指令地址和指令数都会不同，并且在那里调试器出错了，并且可能会向您显示要分析的错误数据。因此，在同一平台上分析内核总是好的，或者如果您可以将所有需要的共享库复制到其他机器并通过 set solib-absolute-prefix 设置路径。

于 2010-08-25T12:04:56.777 回答
2

根据我分析在其他系统上生成的核心文件的经验，它不起作用，因为标准库（以及您的程序可能使用的其他库）通常会有所不同，因此函数的地址也不同，因此您甚至无法获得合理的回溯。

不要这样做，因为即使它有时有效，你也不能依赖它。

于 2010-08-25T09:53:37.787 回答
1

你可以随时运行gdb -c /path/to/corefile /path/to/program_that_crashed。但是，如果 program_that_crashed 没有调试信息（即未编译并与-ggcc/ld 标志链接），除非您是核心调试专家，否则 coredump 就没有那么有用；-)

请注意，可以禁用核心文件的生成（很可能在大多数发行版中默认禁用）。见man ulimit。调用ulimit -c查看核心文件的限制，“0”表示禁用。ulimit -c unlimited在这种情况下尝试。如果施加大小限制，核心转储将不会超过限制大小，因此可能会切断有价值的信息。

此外，生成 coredump 的路径取决于 /proc/sys/kernel/core_pattern。用于cat /proc/sys/kernel/core_pattern查询当前模式。它实际上是一个路径，如果它不以它开头，/那么该文件将在进程的当前工作目录中生成。如果cat /proc/sys/kernel/core_uses_pid返回“1”，则 coredump 将以崩溃进程的文件 PID 作为文件扩展名。您也可以设置这两个值，例如echo -n /tmp/core > /proc/sys/kernel/core_pattern将强制在 /tmp 中生成所有核心转储。

于 2010-08-25T09:01:02.183 回答
0

我将问题理解为：

我怎么可能分析在该操作系统的另一个版本下在一个版本的操作系统下生成的内核？

仅仅因为你很幸运（即使那是有问题的）。尝试这样做会导致很多事情出错：

  • 工具链gcc等gdb会有不同的版本
  • 共享库将具有不同的版本

所以不，你不应该依赖它。

于 2010-08-25T09:49:45.333 回答
-1

您已经提出了类似的问题并接受了答案，当然是自己在这里：Analyzing core file of shared object

加载核心文件后，您可以获取堆栈跟踪并获取最后一个函数调用并检查代码以了解崩溃的原因。

这里有一个小教程可以开始。

编辑：

假设您想知道如何在 linux 上使用 gdb 分析核心文件，因为您的问题还不清楚。

于 2010-08-25T08:58:21.963 回答