How to read, understand, analyze and debug a Linux kernel panic?

陌路散爱 提交于 2019-11-28 14:26:32

问题


Consider the following linux kernel dump stack trace, you can trigger a panic from the kernel source code by calling panic("debugging a linux kernel panic");:

[<001360ac>] (unwind_backtrace+0x0/0xf8) from [<00147b7c>] (warn_slowpath_common+0x50/0x60)
[<00147b7c>] (warn_slowpath_common+0x50/0x60) from [<00147c40>] (warn_slowpath_null+0x1c/0x24)
[<00147c40>] (warn_slowpath_null+0x1c/0x24) from [<0014de44>] (local_bh_enable_ip+0xa0/0xac)
[<0014de44>] (local_bh_enable_ip+0xa0/0xac) from [<0019594c>] (bdi_register+0xec/0x150)
  • In unwind_backtrace+0x0/0xf8 what the +0x0/0xf8 stands for?
  • How can I see the C code of unwind_backtrace+0x0/0xf8?
  • How to interpret the panic's content?

回答1:


It's just an ordinary backtrace, those functions are called in reverse order (first one called was called by the previous one and so on):

unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150

The bdi_register+0xec/0x150 is the symbol + the offset/length there's more information about that in Understanding a Kernel Oops and how you can debug a kernel oops. Also there's this excellent tutorial on Debugging the Kernel

Note: as suggested below by Eugene, you may want to try addr2line first, it still needs an image with debugging symbols though, for example

addr2line -e vmlinux_with_debug_info 0019594c(+offset)




回答2:


Here are 2 alternatives for addr2line. Assuming you have the proper target's toolchain you can do one of the following:

Use objdump:

  1. locate your vmlinux or the .ko file under the kernel root directory, then disassemble the object file :

    objdump -dS vmlinux > /tmp/kernel.s
    
  2. Open the generated assembly file, /tmp/kernel.s. with a text editor such as vim. Go to unwind_backtrace+0x0/0xf8, i.e. search for the address of unwind_backtrace + the offset. Finally, you have located the problematic part in your source code.

Use gdb:

IMO, an even more elegant option is to use the one and only gdb. Assuming you have the suitable toolchain on your host machine:

  1. Run gdb <path-to-vmlinux>.
  2. Execute in gdb's prompt: list *(unwind_backtrace+0x10).

For additional information you may checkout the following:

  1. Kernel Debugging Tricks.
  2. Debugging The Linux Kernel Using Gdb



回答3:


In unwind_backtrace+0x0/0xf8 what the +0x0/0xf8 stands for?

The first number (+0x0) is the offset from the beginning of the function (unwind_backtrace in this case). The second number (0xf8) is the total length of the function. Given these two pieces of information, if you already have a hunch about where the fault occurred this might be enough to confirm your suspicion (you can tell (roughly) how far along in the function you were).

To get the exact source line of the corresponding instruction (generally better than hunches), use addr2line or the other methods in other answers.



来源:https://stackoverflow.com/questions/13468286/how-to-read-understand-analyze-and-debug-a-linux-kernel-panic

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!