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?
Here are 2 alternatives for
addr2line
. Assuming you have the proper target's toolchain you can do one of the following:Use
objdump
:locate your
vmlinux
or the.ko
file under the kernel root directory, then disassemble the object file :Open the generated assembly file,
/tmp/kernel.s
. with a text editor such asvim
. Go tounwind_backtrace+0x0/0xf8
, i.e. search for the address ofunwind_backtrace
+ theoffset
. 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:gdb <path-to-vmlinux>
.list *(unwind_backtrace+0x10)
.For additional information you may checkout the following:
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):
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 KernelNote: 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)
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.