恢复导致内核恐慌的代码行

编程问答 2022-05-29

问题描述

我正在运行 CentOS 8.1，我的机器出现内核崩溃。我安装了 kernel-debuginfo 软件包，并且通常按照 Section 7.11 : Analyzing a core dump 中的步骤进行操作。

这是我的调试会话的缩写版本：

# crash /usr/lib/debug/usr/lib/modules/4.18.0-147.el8.x86_64/vmlinux /var/crash/XXX/vmcore
.
.
. 
WARNING: kernel relocated [336MB]: patching 93296 gdb minimal_symbol values

      KERNEL: /usr/lib/debug/usr/lib/modules/4.18.0-147.el8.x86_64/vmlinux
    DUMPFILE: /var/crash/XXX/vmcore  [PARTIAL DUMP]
        CPUS: 48
        DATE: Sun Jan 10 13:36:04 2021
      UPTIME: 23 days,22:18:40
LOAD AVERAGE: 10.00,10.01,10.00
       TASKS: 1966
    NODENAME: YYY
     RELEASE: 4.18.0-147.el8.x86_64
     VERSION: #1 SMP Wed Dec 4 21:51:45 UTC 2019
     MACHINE: x86_64  (2794 Mhz)
      MEMORY: 2035.9 GB
       PANIC: "Kernel panic - not syncing: Hard LOCKUP"
         PID: 27666
     COMMAND: "R"
        TASK: ffff8ff017978000  [THREAD_INFO: ffff8ff017978000]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 27666  TASK: ffff8ff017978000  CPU: 2   COMMAND: "R"
 #0 [ffffb5187c6c7a50] machine_kexec at ffffffff96057c4e
 #1 [ffffb5187c6c7aa8] __crash_kexec at ffffffff96155b8d
 #2 [ffffb5187c6c7b70] panic at ffffffff960b0578
 #3 [ffffb5187c6c7bf8] watchdog_overflow_callback.cold.8 at ffffffff9618bb11
 #4 [ffffb5187c6c7c08] __perf_event_overflow at ffffffff961f54f2
 #5 [ffffb5187c6c7c38] x86_pmu_handle_irq at ffffffff96007a16
 #6 [ffffb5187c6c7e88] amd_pmu_handle_irq at ffffffff96008b14
 #7 [ffffb5187c6c7ea0] perf_event_nmi_handler at ffffffff960060cd
 #8 [ffffb5187c6c7eb8] nmi_handle at ffffffff96021843
 #9 [ffffb5187c6c7f10] default_do_nmi at ffffffff96021cce
#10 [ffffb5187c6c7f30] do_nmi at ffffffff96021ea8
#11 [ffffb5187c6c7f50] nmi at ffffffff96a01537
    RIP: 0000146816a69d6e  RSP: 00007ffc378f6270  RFLAGS: 00000216
    RAX: 000000006655e8df  RBX: 0000000000000003  RCX: 000000000003ad90
    RDX: 0000000000000003  RSI: 0000000007ccb060  RDI: 000000076fe90140
    RBP: 0000000000085fc6   R8: 0000000000b13039   R9: 00000007770c0758
    R10: 0000000778ba8a38  R11: 0000000000000c36  R12: 000000000070e070
    R13: 0000000000000000  R14: 00007ffc378f6410  R15: 00007ffc378f6430
    ORIG_RAX: ffffffffffffffff  CS: 0033  SS: 002b

显然，罪魁祸首是我正在运行的 R 进程（请参阅 COMMAND: "R"）。查看上面的 bt ，它似乎只返回内核级函数。我想知道我的 R 代码（或安装的 R 库）中的哪一行导致了问题。尝试

crash> gdb bt
No stack.
gdb: gdb request failed: bt
crash>

没有用。看看 man crash 如何做到这一点并不明显。可能涉及的一些 R 库具有使用调试标志编译的 C++ 代码。我对错误的原因有一个模糊的希望。

问题：

  1. 如何使用 Linux crash 实用程序来恢复导致内核崩溃的代码行（R 或 C++）？

  2. 什么是“内核恐慌 - 不同步：硬锁定”

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）

crashlinuxlinuxpanicrr