3.4. 调试 Crashed 应用程序

流程

1. 要启用内核转储，请确保 /etc/systemd/system.conf 文件包含以下行：

   DumpCore=yes
   DefaultLimitCORE=infinity

   您还可以添加注释，描述之前是否存在这些设置以及之前的值。如果需要，这将使您稍后撤销这些更改。注释是以 # 字符开头的行。

   更改该文件需要管理员级别访问权限。

2. 应用新配置：

   # systemctl daemon-reexec

3. 删除内核转储大小的限制：

   # ulimit -c unlimited

   要反向更改，请使用值 0 而不是 unlimited 来运行 命令。

4. 安装提供 sosreport 工具来收集系统信息的 sos 软件包：

   # dnf install sos

5. 当应用程序崩溃时，会生成核心转储，并由 systemd-coredump 处理。

6. 创建 SOS 报告以提供有关系统的更多信息：

   # sosreport

   这将创建一个包含您系统信息的 .tar 存档，如配置文件的副本。

7. 找到内核转储：

   $ coredumpctl list executable-name

8. 导出内核转储：

   $ coredumpctl dump executable-name > /path/to/file-for-export

   如果应用程序多次崩溃，则第一个命令的输出列出了更多捕获的内核转储。在这种情况下，使用其他信息为第二个命令构建更精确的查询。详情请查看 coredumpctl(1) 手册页。

9. 将内核转储和 SOS 报告传送到进行调试的计算机。另外，也传输可执行文件（如果该文件已知）。

   重要

   当可执行文件未知时，core 文件的后续分析会识别该文件。

10. 可选：在传输后将内核转储和 SOS 报告删除，以释放磁盘空间。

流程

1. 要识别发生崩溃的可执行文件，请运行带内核转储文件的 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

   输出中包含一行中每个模块的详细信息，用空格分开。该信息按以下顺序列出：

   1. 模块映射的内存地址
   2. 模块的 build-id 以及它在找到的内存中的位置
   3. 模块的可执行文件名称，如果未知显示为 -，如果模块没有从文件中加载则显示为 .。
   4. 调试信息的来源，在可用时显示为一个文件名，当包括在可执行文件本身中时显示为 .，或在不存在时显示 -
   5. 主模块的共享库名称(soname)或 [exe]

   在本例中，重要的细节是文件名 /usr/bin/sleep 以及在包括文本 [exe] 的行中的 build-id 2818b2009547f780a5639c904cded443e564973e。使用这些信息，您可以识别分析内核转储所需的可执行文件。

2. 获取崩溃的可执行文件。

   • 如果可能，在发生崩溃的系统中复制它。使用从核心文件中提取的文件名。

   • 您还可以在系统中使用相同的可执行文件。Red Hat Enterprise Linux 上构建的每个可执行文件都包含带有唯一 build-id 值的备注。确定相关本地可用可执行文件的构建 ID：

     $ eu-readelf -n executable_file

     使用此信息将远程系统中的可执行文件与您的本地副本匹配。内核转储中列出的本地文件和 build-id 的 build-id 必须匹配。

   • 最后，如果应用程序从 RPM 软件包安装，您可以从软件包中获取可执行文件。使用 sosreport 输出来查找所需软件包的确切版本。
3. 获取可执行文件使用的共享库。对可执行文件使用的步骤相同。
4. 如果应用程序以软件包的形式发布，在 GDB 中加载可执行文件，以显示缺少 debuginfo 软件包的提示。如需了解更多详细信息，请参阅使用 GDB 获取应用程序或库的 debuginfo 软件包。

5. 要详细检查核心文件，使用 GDB 加载可执行文件和内核转储文件：

   $ gdb -e executable_file -c core_file

   有关缺失的文件和调试信息的进一步消息可帮助您识别调试会话中缺少什么。如果需要，返回到上一步。

   如果应用程序的调试信息可作为文件而不是软件包提供，使用 symbol-file 命令在 GDB 中载入该文件：

   (gdb) symbol-file program.debug

   使用实际文件名替换 program.debug。

   注意

   对于核心转储中包含的所有可执行文件，可能不需要安装调试信息。这些可执行文件的大部分是应用代码使用的库。这些库可能不会直接为问题贡献，您不需要为它们包含调试信息。

6. 使用 GDB 命令在应用程序崩溃时检查应用程序状态。请参阅使用 GDB 检查应用程序内部状态。

   注意

   在分析内核文件时，GDB 不会附加到正在运行的进程。用于控制执行的命令无效。

7. 要在应用程序终止时只查看应用程序的堆栈，请使用 eu-stack 工具打开核心文件：

   $ *eu-stack --core __core-file__*

   这将显示应用的堆栈的列表。

流程

1. 根据可执行文件名称的已知部分，查找挂起进程的 PID：

   $ pgrep -a executable-name-fragment

   这个命令会以以下形式输出一行

   PID command-line

   使用 命令行 值来验证 PID 属于预期进程。

   例如：

   $ pgrep -a bc

   5459 bc

2. 向进程发送中止信号：

   # kill -ABRT PID

3. 验证 coredumpctl 是否捕获了内核：

   $ coredumpctl list PID

   例如：

   $ coredumpctl list 5459

   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. 根据需要进一步检查或使用 core 文件。

   您可以根据 PID 和其他值指定内核转储。详情请查看 coredumpctl(1) 手册页。

   后续步骤

   • 要显示核心文件的详情，请运行：

     $ coredumpctl info PID

   • 要在 GDB 调试器中载入核心文件，请运行：

     $ coredumpctl debug PID

     根据调试信息的可用性，GDB 可能会建议运行命令，例如：

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-23.el10.x86_64

     有关此过程的详情，请参阅使用 GDB 获取应用程序或库的 debuginfo 软件包。

   • 要导出核心文件以便进一步处理其他位置，请运行：

     $ coredumpctl dump PID > /path/to/file_for_export

   • 使用您要放置内核转储的文件替换 /path/to/file_for_export。

     $ coredumpctl dump PID > /path/to/file_for_export

流程

1. 查找进程 ID(pid)。使用 ps、pgrep 和 top 等工具：

   $ ps -C some-program

2. 转储这个进程的内存：

   $ gcore -o filename pid

   这会创建一个文件 filename 并转储进程内存。转储内存时，进程的执行将停止。

3. 在内核转储完成后，进程会恢复正常执行。

4. 创建 SOS 报告以提供有关系统的更多信息：

   # sosreport

   这会创建一个 tar 存档，其中包含您的系统信息，如配置文件的副本。

5. 将程序的可执行文件、内核转储和 SOS 报告传送到进行调试的计算机。
6. 可选：在传输后将内核转储和 SOS 报告删除，以释放磁盘空间。

流程

1. 将 GDB 设置为忽略 /proc/PID/coredump_filter 文件中的设置：

   (gdb) set use-coredump-filter off

2. 将 GDB 设置为忽略内存页标记 VM_DONTDUMP ：

   (gdb) set dump-excluded-mappings on

3. 转储内存：

   (gdb) gcore core-file

   使用您要转储内存的文件名替换 core-file。