如何快速定位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?都有介绍，我们将针对上面的实例做更具体的分析。

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

情况一

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

情况二

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

用途：不挂断地运行命令。

语法：nohup Command [ Arg … ] [　&]

无论是否将 nohup 命令的输出重定向到终端，输出都将附加到当前目录的 nohup.out 文件中。

如果当前目录的 nohup.out 文件不可写，输出重定向到 $HOME/nohup.out 文件中。

如果没有文件能创建或打开以用于追加，那么 Command 参数指定的命令不可调用。

退出状态：该命令返回下列出口值：

126 可以查找但不能调用 Command 参数指定的命令。

127 nohup 命令发生错误或不能查找由 Command 参数指定的命令。

否则，nohup 命令的退出状态是 Command 参数指定命令的退出状态。

用途：在后台运行

一般两个一起用

3.为什么呢 2>&1 要写在后面？

首先是command >file将标准输出重定向到file中， 2>&1 是标准错误拷贝了标准输出的行为，也就是同样被重定向到file中，最终结果就是标准输出和错误都被重定向到file中。

2>&1 标准错误拷贝了标准输出的行为，但此时标准输出还是在终端。>file 后输出才被重定向到file，但标准错误仍然保持在终端。

用strace可以看到：

这个命令中实现重定向的关键系统调用序列是：

open(file) == 3

dup2(3,1)

dup2(1,2)

这个命令中实现重定向的关键系统调用序列是：

dup2(1,2)

open(file) == 3

dup2(3,1)

注意：0 是标准输入（STDIN），1 是标准输出（STDOUT），2 是标准错误输出（STDERR）。

这里的2和>之间不可以有空格，2>是一体的时候才表示错误输出。

---