如何快速定位Linux Panic出错的代码行

内核Panic时，一般会打印回调，并打印出当前出错的地址：

kernel/panic.c:panic():

#ifdef CONFIG_DEBUG_BUGVERBOSE

/*

* Avoid nested stack-dumping if a panic occurs during oops processing

*/

if (!test_taint(TAINT_DIE) &&oops_in_progress <= 1)

dump_stack()

#endif

而dump_stack()调用关系如下：

dump_stack() -->__dump_stack() -->show_stack() -->dump_backtrace()

dump_backtrace()会打印整个回调，例如：

[<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)

通常，上面的回调会打印出出错的地址。

解决方案

通过分析，要快速定位出错的代码行，其实就是快速查找到出错的地址对应的代码？

相应的工具有addr2line, gdb, objdump等，这几个工具在How to read a Linux kernel panic?都有介绍，我们将针对上面的实例做更具体的分析。

需要提到的是，代码的实际运行是不需要符号的，只需要地址就行。所以如果要调试代码，必须确保调试符号已经编译到内核中，不然，回调里头打印的是一堆地址，根本看不到符号，那么对于上面提到的情况二而言，将无法准确定位问题。

情况一

在代码编译连接时，每个函数都有起始地址和长度，这个地址是程序运行时的地址，而函数内部，每条指令相对于函数开始地址会有偏移。那么有了地址以后，就可以定位到该地址落在哪个函数的区间内，然后找到该函数，进而通过计算偏移，定位到代码行。

情况二

但是，如果拿到的日志文件所在的系统版本跟当前的代码版本不一致，那么编译后的地址就会有差异。那么简单地直接通过地址就可能找不到原来的位置，这个就可能需要回调里头的函数名信息。先通过函数名定位到所在函数，然后通过偏移定位到代码行。

Panic()函数（实际上是User::Panic()）是当系统发现无法继续运行下去的故障时将调用它，会导致程序中止，然后由系统显示错误号。

内核的panic 函数（即panic()）的程序代码 就放在内核源码树里的kernel/panic.c 文件中。

---