时间戳

首页 > 解决方案 > 恢复导致内核恐慌的代码行

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

问题描述

我正在运行 CentOS 8.1，我的机器出现内核恐慌。我安装了kernel-debuginfo包，我通常遵循第 7.11 节中的步骤：分析核心转储。

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

# 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. 如何使用 Linuxcrash实用程序恢复导致内核崩溃的代码行（R 或 C++）？

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

标签： rlinuxcrashgdbpanic

解决方案

推荐阅读