如何解决Oop问题

看到有人贴出oops的消息不禁想了解一下在linux下大家是如何解决这类问题的。

因为刚开始学习linux内核，所以也只是略知一二，现在就将我的了解说说：

1. Oops是什么？

看LKD对oops的描述，oops就应该是unix系统的system panic，叫法不同而已。

什么是panic呢？简单的说就是内核程序错误引发的一种debug和保护机制，系统会dump出内核映像，里面包含了当时CPU的状态，进程的状态，内核堆，栈的状态...最直观的最重要的恐怕就是 调用栈的back trace.

很多情况下，一个oops是可以被重现的，根据调用栈的back trace和printk也许就搞定了问题。
但更多的时候，一个oops是很难重现，比如一个race condition.
这时候，分析一个oops之后的crash dump文件就变得尤为重要了。

2. 如何分析oops.

分析panic的思路和分析应用程序coredump的思路一样的。

首先，要看调用的backtrace和错误消息.

看程序是在哪个函数产生发生了错误，看消息里面有什么有价值的信息，比如空指针引用之类的。


其次，了解了backtrace在什么位置，就可以结合源代码来看是否有问题了。

幸运的话，光看具体函数的代码也许就会发现问题。

但多数时候，还需要检查crash dump的映像文件的。

这时候，一个好用的帮助分析crash dump的工具就尤为重要了。

在solaris下，我们可以通过mdb来查看panic时在CPU运行的所有线程的状态，

CPU寄存器的状态，信号量，锁...
因为IA32的特性，调用栈、backtrace里面每个函数的参数，都可以得到。
此外还有堆的状态。

通过以上这些数据，我们会试图重新描绘出系统崩溃那一刹那，发生了什么。


在linux下，该如何做类似的分析工作呢？

因为种种原因，linux至今没有集成kernel debug工具，但还是有一些第3方工具可用：

1.kdb

特点：二进制，汇编级的调试工具。只需要一台机器。


2.kgdb

特点：源代码级的调试工具，但需要两台机器，null modem线连接。

局限：需要patch重新编译内核。而且，在事后分析crash dump文件的情况下，尤其是当oops不可重现时，只能在汇编和二进制下工作了。


3.gdb

特点：linux环境中自带

局限：功能有限，但检查crash dump也许足够了。

linus本人不提倡用kernel debug工具，那他们是如何检查一个crash dump文件的呢？我猜想是用gdb

4.其它工具和方法...




大家不妨谈谈自己学习和使用这些工具的心得，拿出知道的一些资料共享一下。

[ 本帖最后由 Solaris12 于 2006-1-11 11:58 编辑 ]



说实在的，上面那些东西我都没用过。
一般内核出了问题，用最原始的方法，oops信息 ＋反汇编，现在还没碰到解决不了的。如果是中断或者CPU硬件出了问题，用仿真器，曾经移植过一个全新的ARCH，调试过程确实很痛苦。

Documentation下面有一个调试内存的例子，非常好，有兴趣的可以研究一下。
调试工具问题是嵌入式系统不稳定。

Nlkd最近在研究，听说是个好东西。


qemu那个东西也值得去学一下。