![如何理解内核恐慌 core dump 输出?](https://linux22.com/image/632/%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E6%A0%B8%E6%81%90%E6%85%8C%20core%20dump%20%E8%BE%93%E5%87%BA%EF%BC%9F.png)
这是我运行我的应用程序之一时得到的输出:
Kernel bug detected[#1]:
Cpu 0
$ 0 : 00000000 00000000 0fffff00 0fffff00
$ 4 : c6800000 850b7780 8b0043c0 00000040
$ 8 : 000004ac 000004ac 00000002 844e8000
$12 : 00000000 feced300 8430d2ac 0000000a
$16 : 00000040 000000fc 8b759300 00000001
$20 : 00000012 84370000 00000004 00000009
$24 : 00000000 8403d4f4
$28 : 8b1c0000 8b1c3ee0 0000000a 84255764
Hi : 003d08ef
Lo : 79432700
epc : 840a754c 0x840a754c
Tainted: P
ra : 84255764 0x84255764
Status: 1100dc03 KERNEL EXL IE
Cause : 00800034
PrId : 00019749 (MIPS 74Kc)
Modules linked in: em8xxxcursor(P) em8xxxfb em8xxxcopybit(P) pmem_rua em8xxx(P) llad(P)
Process events/0 (pid: 4, threadinfo=8b1c0000, task=8b0323d8, tls=00000000)
Stack : 8b0323d8 8402d074 843d0c68 843d10e8 8b1c3f80 8b0323d8 843d0cc8 8b2d6de8
8b2d6de8 8402d194 00000003 00000000 00000000 84300000 84374104 8b124c80
84255238 fffffffc efffffff 8431d16c 8431d1a4 00000000 00000000 8404c364
8404cc6c 00000001 8b124c88 8b124c80 8b124c88 8b124c80 8b1c3f80 00000000
00000000 00000000 00000000 8404cc04 8b03254c 8b03254c 84051638 00000000
...
Call Trace:[<8402d074>] 0x8402d074
[<8402d194>] 0x8402d194
[<84255238>] 0x84255238
[<8404c364>] 0x8404c364
[<8404cc6c>] 0x8404cc6c
[<8404cc04>] 0x8404cc04
[<84051638>] 0x84051638
[<84051b14>] 0x84051b14
[<8404cba8>] 0x8404cba8
[<84051650>] 0x84051650
[<8401504c>] 0x8401504c
Code: 3c030fff 3463ff00 00431024 <00028036> 09029cfd 24050001 27bdffc8 0085102b afb7002c
Kernel panic - not syncing: Fatal exception in interrupt
我可以从这个转储中获取有关导致这种情况发生的问题的一些信息吗?
答案1
如果可以将核心转储与符号表关联起来,那么它们会更容易阅读。这样,调试工具可以将内存映射地址转换为助记符,即数据结构、函数名称、全局变量等。其一,上面的调用跟踪会更有帮助。
对于恐慌引起的转储,读取核心转储的常用方法是从故障追溯到可能的原因。最有可能跟踪的线索是在故障点执行的进程。在大多数内核中,有了适当的调试符号信息,您就可以逐条指令后退一步,找到错误的值。
我不熟悉此输出的表示形式,但看起来您的内核可能在断言不应到达中断的状态下收到了中断。这种规则是在数据计算似乎不安全时防止数据计算的,因此内核会发生恐慌以防止修改。不过,这只是我的猜测。
许多内核在运行时都剥离了所有符号信息,以尽可能地精简。看起来您必须将这些值编译到内核中才能获得更容易消化的恐慌输出。