21.3. 使用内核转储检查应用程序 rash 状态
先决条件
- 您有一个内核转储文件和 SOS 报告
- GDB 和 elfutils 已安装在系统上
步骤
要识别发生崩溃的可执行文件,请使用核心转储文件运行
eu-unstrip命令:$ eu-unstrip -n --core=./core.9814 0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe] 0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1 0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6 0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2输出包含一个行中每个模块的详情,用空格分开。此信息按以下顺序列出:
- 映射模块的内存地址
- 模块的 build-id 及其在内存中的位置
-
模块的可执行文件名称,如果未从文件加载为
- 时显示为 -when unknown 或 等。 -
调试信息源(如果可用时显示为文件名),如
包含在可执行文件本身中,或(如果根本不存在) -
主模块的共享库名称(soname)或
[exe]
在本例中,重要的详细信息是文件名
/usr/bin/sleep和 build-id2818b2009547f780a5639c904cded443e564973eon the text[exe]。使用此信息,您可以识别分析核心转储所需的可执行文件。获取崩溃的可执行文件。
- 如果可能,请从发生崩溃的系统中复制它。使用从 core 文件提取的文件名。
或者,在您的系统上使用相同的可执行文件。在 Red Hat Enterprise Linux 上构建的每个可执行文件都包含带有唯一 build-id 值的备注。确定相关的本地可用可执行文件的 build-id:
$ eu-readelf -n executable_file使用此信息将远程系统上的可执行文件与您的本地副本匹配。内核转储中列出的本地文件和 build-id 的 build-id 必须匹配。
-
最后,如果应用程序是从 RPM 软件包安装的,您可以从 软件包中获取可执行文件。使用
sosreport输出来查找所需软件包的确切版本。
- 获取由可执行文件使用的共享库。将与 相同的步骤用于 可执行文件。
- 如果应用程序以软件包形式分发,请在 GDB 中加载可执行文件,以显示缺少 debuginfo 软件包的提示。如需了解更多详细信息,请参阅 第 20.1.4 节 “使用 GDB 获取应用程序或库的调试信息软件包”。
要详细检查核心文件,使用 GDB 加载可执行文件和核心转储文件:
$ gdb -e executable_file -c core_file有关缺少文件和调试信息的其他消息可帮助您识别调试会话缺少的内容。如果需要,返回到上一步骤。
如果调试信息以文件而不是软件包形式提供,请使用
symbol-file命令在 GDB 中载入此文件:(gdb) symbol-file program.debug使用实际文件名替换 program.debug。
注意可能不需要为核心转储中包含的所有可执行文件安装调试信息。这些可执行文件的大部分是应用代码使用的库。这些库可能不会直接导致您要分析的问题,您不需要为它们包含调试信息。
在应用崩溃时,使用 GDB 命令检查应用的状态。请参阅 第 20.2 节 “使用 GDB 检查应用程序的内部状态”。
注意分析核心文件时,GDB 未附加到正在运行的进程。控制执行的命令无效。
其它资源
- 使用 GDB 进行调试 - 2.1.1 选择文件
- 使用 GDB 进行调试 — 18.1 Commands to Specify Files
- 使用 GDB 进行调试 — 18.3 Debugging Information in Separate Files