学习笔记

Posted 2020-06-30 20135302魏静静

 第十八章 调试

一、内核中的bug

内核bug的原因可能有：

- 错误代码
- 同步时发生的错误，例如共享变量锁定不当
- 错误的管理硬件
- ……

内核bug发作的症状可能有：

- 降低所有程序的运行性能
- 毁坏数据
- 使得系统处于死锁状态
- ……

内核开发比起用户开发要多考虑一些独特的问题，比如：

- 定时限制
- 竞争条件
- ……
原因是允许多个线程在内核中同时运行。

二、通过打印来调试

1. 健壮性

• 弹性极佳的函数：任何时候、任何地方都能调用它
  • 可以在中断上下文和进程上下文中被调用
  • 可以在任何持有锁时被调用
  • 可以在多处理器上同时被调用
• 除非再启动过程中的初期就要在终端上输出

2. 日志等级

• printk()和printf()在使用上最主要的区别就是前者可以指定一个日志级别。内核通过这个级别来判断是否在终端上打印消息。

• 内核把级别比某个特定值低的所有消息显示在终端上。

• 如果没有指定一个记录等级，函数会选用默认的DEFAULT_MASSAGE_LOGLEVEL。

• 内核会把这些记录等级转化，n指等级，从0-7，对应表中从上到下，数字越小越重要。

         0   KERN_EMERG  最重要
          7   KERN_DEBUG  最不重要

• 调试信息， 有两种赋予记录等级的方法：

  • • 保持终端的默认记录等级不变，给所有调试信息KERN_CRIT或更低的等级。
    • 给所有调试信息KERN_DEBUG等级，调整终端的默认记录等级。

• printk的输出日志级别如下:

等级	描述
KERN_ EMERG	一个紧急情况
KERN_ ALERT	一个需要立即被注意到的错误
KERN_ CRIT	一个临界情况
KERN_ ERR	一个错误
KERN_ WARNING	一个警告
KERN_ NOTICE	一个普通的, 不过也有可能需要注意的情况
KERN_ INFO	一条非正式的消息
KERN_ DEBUG	一条调试信息--一般是冗余信息

 

 

3. 缓冲区

1. 内核消息都被记录在环形队列中，以队列方式进行读写；大小可以通过设置CONFIGLOGBUF_SHIFT进行调整
2. 在单处理器上，该缓冲区大小默认为16KB，也就是说，超过的消息将覆盖旧消息
3. 优势：
   1. 读写同步问题容易解决
   2. 记录的维护更加方便

 

4. 相关进程

1. 用户空间的守护进程——klogd从记录缓冲区中读取内核信息，再通过syslogd守护进程将它们保存在系统日志文件中
   1. klogd会阻塞知道==直到有新的内核消息可供读出。被唤醒之后，它会读出新的内核消息并进行处理（默认情况下，就是传递给syslogd）；
   2. syslogd会将所有接收到的消息添加到（默认情况下是messages）文件中

三、oops

oops是内核告知用户有不幸发生的最常用的方式。
内核很难自我修复，也不能将自己杀死，只能发布oops，过程包括：

- 向终端上输出错误消息
- 输出寄存器中保存的信息
- 输出可供跟踪的回溯线索

通常发送完oops之后，内核会处于一种不稳定状态。

关于oops发生的时机：

1. 发生在中断上下文：内核无法继续，会陷入混乱，导致系统死机
2. 发生在idle进程或init进程（0号进程和1号进程），同上
3. 发生在其他进程运行时，内核会杀死该进程并尝试着继续执行

内和调试配置项：

1. 配置项：CONFIGDEBUGKERNEL
2. 选项 之 sleep-inside-spinlockchecking（自旋锁内睡眠选项）——正在使用自旋锁或者禁止抢占的代码进行的是原子操作，不可更改
3. 探测范围：
   • 正在使用锁的时候调用schedule();
   • 正使用锁的时候以阻塞方式请求分配内存；
   • 引用单CPU数据时睡眠

引发bug并打印信息：

1. 利用BUG()以及BUG_ON（）（因为大多数体系结构都把这两个函数定义成某种非法操作，可以触发oops）
   • 当做断言或者条件语句
2. 调用panic()函数会在打印错误信息的同时挂起系统
   • panic("terrible thing"，terrible_thing)；
3. 调用dump_stack()，只在终端上打印寄存器上下文及函数的跟踪线索

系统请求键

1. 配置项：CONFIGMAGICSYSR配置选项来启动；此外，通过/proc/sys/kernel/sysrq标记该特性的开关
2. 优点：无论内核处于什么状态，都可以通过特殊的组合键跟内核进行通信
3. 常见的命令
   • SysRq-b:重启设备
   • SysRq-o:关闭机器
   • SysRq-u:卸载所有的文件系统
   • SysRq-s:把所有已安装的文件系统都刷新到磁盘

oops中包含的重要信息：寄存器上下文和回溯线索

1. 回溯线索：显示了导致错误发生的函数调用链。

• 寄存器上下文信息也很有用，比如帮助冲进引发问题的现场

• • ksymoops

                  回溯线索中的地址需要转化成有意义的符号名称
                  ——需要调用ksymoops命令。
                 并且还必须提供编译内核时产生的System.map。如果用的是模块，还需要一些模块信息。

           kysmoop saved_oops.txt

• • kallsyms

                现在的版本中不需要使用sysmoops这个工具，因为可能会发生很多问题，新版本中引入了kallsyms疼，可以通过定义CONFIG_KALLSYMS配置选项启用。

四、内核调试器

1.gdb

可以使用标准的GNU调试器对正在运行的内核进行查看。
针对内核启动调试器的方法与针对进程的方法大致相同：

gdb vmlinux /proc/kcore

vmlinx:未经压缩的内核映像，区别于zImage或bImage，它存放于源代码树的根目录上。
/proc/kcore作为一个参数选项，是作为core文件来用的，通过它能够访问到内核驻留的高端内存。只有超级用户才能读取此文件的数据

可以使用gdb的所有命令来获取信息。例如：

打印一个变量的值：
p global_variable

反汇编一个函数：
disassemble function

-g参数还可以提供更多的信息。

局限性：

1. 没有办法修改内核数据
2. 不能单步执行内核代码

2.kgdb

是一个补丁 ，可以让我们在远程主机上通过串口利用gdb的所有功能对内核进行调试。
需要两台计算机：仪态运行带有kgdb补丁的内核，第二胎通过串行线使用gdb对第一台进行调试。
通过kgdb，gdb的所有功能都能使用:

- 读取和修改变量值
- 设置断点
- 设置关注变量
- 单步执行

五、探测系统

1.使用uid作为选择条件

一般情况下，加入特性时，只要保留原有的算法而把新算法加入到其他位置上，基本就能保证安全。

可以把用户id（UID）作为选择条件来实现这种功能：
通过某种选择条件，安排到底执行哪种算法。
例如：

if (current-> uid !=7777) {
    /* 老算法…… */
} else {
    /* 新算法…… */
}

即，除了uid=7777的用户以外，其他所有的用户都是用的老算法，所以这个7777用户可以专门用来测试新算法。

2.使用条件变量

如果代码与进程无关，或者希望有一个针对所有情况都能使用的机制来控制某个特性，可以使用条件变量。
这种方式比使用UID更简单，只需要创建一个全局变量作为一个条件选择开关：

• 如果该变量为0，就使用某一个分支上的代码；
• 否则，选择另外一个分支。

操控方式：某种接口，或者调试器。

3.使用统计量

这种方法常用于使用者需要掌握某个特定事件的发生规律的时候。
方法是创建统计量，并提供某种机制访问其统计结果。

4.重复频率限制

当系统的调试信息过多的时候，有两种方式可以防止这类问题发生：

• 重复频率限制
• 发生次数限制