Kernel Exception 问题分析流程

3a5f4ccb0ef321e267511e7f7b1fb3da.gif

和你一起终身学习,这里是程序员Android

本篇文章主要介绍 Android 开发中的部分知识点,通过阅读本篇文章,您将收获以下内容:

一、Kernel Exception概述
二、Kernel空间布局
三、printk 概述
四、AEE db log机制
五、前期异常处理
六、die()流程
七、panic()流程
八、nested panic
九、参考文献

一、Kernel Exception(KE)概述

Android OS由3层组成,最底层是Kernel,上面是Native bin/lib,最上层是Java层:

f4c8e4599a109116ede044d465cc0f93.jpeg
Android OS 3层结构

任何软件都有可能发生异常,比如野指针,跑飞、死锁等等。
当异常发生在kernel层,我们就叫它为KE(kernel exception),同理,发生在Native就是NE,Java层就是JE。这篇文章仅关注底层的KE。

1. KE类别

kernel有以下2种(oops、panic)崩溃类别

    1. oops (类似assert,有机会恢复)

oops是美国人比较常有的口语。就是有点意外,吃惊,或突然的意思。内核行为表现为通知感兴趣模块,打印各种信息,如寄存器值,堆栈信息…
当出现oops时,我们就可以根据寄存器等信息调试并解决问题。
/proc/sys/kernel/panic_on_oops为1时导致panic。我们默认设置为1,即oops会发生panic。

    1. panic

    Panic – 困惑,恐慌,它表示Linux kernel遇到了一个不知道该怎么继续的情况。内核行为表现为通知感兴趣模块,死机或者重启。
    在kernel代码里,有些代码加了错误检查,发现错误可能直接调用了panic(),并输出信息提供调试

2. KE常用调试方法

凡是程序就有bug。bug总是出现在预料之外的地方。据说世界上第一个bug是继电器式计算机中飞进一只蛾子,倒霉的飞蛾夹在继电器之间导致了计算机故障。由于这个小虫子,程序中的错误就被称为了bug。

有Bug就需要Debug,而调试是一种很个性化的工作,十个人可能有十种调试方法。但从手段上来讲,大致可分为两类,在线调试 (Online Debug) 和离线调试 (Offline Debug).

3.在线调试

Online debug, 指的是在程序的运行过程中监视程序的行为,分析是否符合预期。通常会借助一些工具,如GDB和Trace32等。有时候也会借助一些硬件设备的协助,如仿真器/JTAG,但是准备环境非常困难,而且用起来也很麻烦,除非一些runtime问题需要外很少使用。

4.离线调试,

Offline debug, 指的是在程序的运行中收集需要的信息,在Bug发生后根据收集到的信息来分析的一种手段。通常也分为两种方式,一种是Logging,一种是Memory Dump。

Logging
日志或者相关信息的收集,可以比较清晰的看到代码的执行过程,对于逻辑问题是一种有效的分析手段,由于其简单易操作,也是最为重要的一种分析手法。

Memory Dump
翻译过来叫做内存转储,指的是在异常发生的时刻将内存信息全部转储到外部存储器,即将异常现场信息备份下来以供事后分析。是针对CPU执行异常的一种非常有效的分析手段。在Windows平台,程序异常发生之后可以选择启动调试器来马上调试。在Linux平台,程序发生异常之后会转储core dump,而此coredump可以用调试器GDB来进行调试。而内核的异常也可以进行类似的转储。

二、Kernel空间布局

在分析KE前,你要了解kernel内存布局,才知道哪些地址用来做什么,可能会是什么问题。

在内核空间中存在如下重要的段:

1. vmlinux代码/数据段:

任何程序都有TEXT(可执行代码),RW(数据段),ZI段(未初始化数据段),kernel也有,对应的是.text,.data,.bss

2.module区域:

kernel可以支持ko(模块),因此需要一段空间用于存储代码和数据段。

3. vmalloc区域:

kernel除了可以申请连续物理地址的内存外,还可以申请不连续的内存(虚拟地址是连续的),可以避免内存碎片化而申请不到内存。

4. io map区域:

留给io寄存器映射的区域,有些版本没有io map区域而是直接用vmalloc区域了。

5.memmap:

kernel是通过page结构体描述内存的,每一个页框都有对应的page结构体,而memmap就是page结构体数组。

还有其他段小的段没有列出来,可能根据不同的版本而差别。

6. ARM64bit kernel布局

目前智能机已进入64bit,因此就存在32bit布局和64bit布局,下面一一讲解。

ARM64可以使用多达48bit物理、虚拟地址(扩充成64bit,高位全为1或0)。对linux kernel来讲,目前配置为39bit的kernel空间。

由于多达512GB的空间,因此完全可以将整个RAM映射进来,0xFFFFFFC000000000之后就是一一映射了,

<think>好的,用户问的是“kernel die流程是什么”。首先,我需要确认用户指的是操作系统内核中的“die”流程。通常,在Linux内核开发中,当遇到无法恢复的错误时,内核会触发panic或oops,但“die”可能指的是更底层的处理流程。 接下来,我应该回顾一下内核错误处理的基本机制。当内核遇到严重错误,比如空指针解引用、内存访问越界等,会调用die()函数。这个函数负责处理当前的异常情况,打印相关的调试信息,比如寄存器状态、堆栈跟踪等,然后可能触发panic导致系统重启。 需要进一步分解die流程的具体步骤。首先,die()函数属于异常处理的一部分,通常在arch目录下的特定架构代码中实现,比如x86的die处理。它会先获取当前的异常信息,然后通过notifier链通知其他子系统,记录错误信息到控制台和日志,最后决定是否继续运行还是panic。 用户可能是在调试内核崩溃的问题,或者对内核的错误处理机制感兴趣。他们可能希望了解当系统发生严重错误时,内核是如何记录信息并采取行动的。因此,需要详细说明die流程的各个阶段,以及相关的函数调用,比如notifier_call_chain、oops_enter/exit等。 另外,要区分die()和panic()的区别。die()处理当前的异常,可能让内核继续运行,而panic()会导致系统停止。需要明确两者在流程中的关系,比如die()可能最终调用panic()。 还要考虑用户可能的背景,是否是内核开发者或系统管理员,他们可能需要了解如何分析内核日志中的die信息,或者如何配置内核以捕获更多调试信息。因此,在解释流程时,可以提到如何利用这些信息进行故障排查。 最后,确保使用正确的中文术语,避免直译造成的歧义。例如,将“stack trace”翻译为“堆栈跟踪”或“调用栈追踪”。同时,结构要清晰,分步骤解释流程,便于用户理解。</think>内核中的 "die" 流程是指当内核遇到无法处理的严重错误时,触发异常处理并生成崩溃信息的完整过程(通常对应 `die()` 函数)。以下是典型处理流程: --- ### **核心处理阶段** 1. **异常触发** - CPU 捕获非法操作(如空指针解引用、内存越界、除零错误) - 硬件生成异常信号(如x86的#GP、#PF异常) 2. **进入die()函数** - 内核调用 `die(const char *str, struct pt_regs *regs, long err)` - 参数包含错误描述字符串、寄存器状态和错误码 3. **关键信息收集** ```c /* 伪代码示例 */ void die(const char *str, struct pt_regs *regs, long err) { oops_enter(); // 进入oops处理 console_verbose(); // 强制控制台输出 __show_regs(regs); // 打印寄存器状态 add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE); // 标记内核污染状态 bust_spinlocks(1); // 解除自旋锁防止死锁 ``` - 打印堆栈跟踪(`dump_stack()`) - 输出内存映射信息(`show_mem()`) 4. **通知链处理** - 通过 `notify_die(DIE_OOPS, str, regs, err, 0, 0)` 调用注册的notifier函数 - 允许调试工具(如kdump)介入 5. **最终处理决策** ```c if (panic_on_oops) panic("Fatal exception"); // 触发内核恐慌 bust_spinlocks(0); oops_exit(); ``` - 根据 `panic_on_oops` 配置决定是否立即panic - 可能尝试杀死当前进程继续运行(非致命错误时) --- ### **关联机制** - **与panic()的关系** die() 可能最终调用 panic(),但更侧重于错误现场记录,而 panic() 是系统级崩溃处理 - **信息输出渠道** - 控制台输出(`printk` 缓冲区) - `dmesg` 日志记录 - 通过kmsg_dump保存到持久存储 - **架构相关实现** x86处理入口:`arch/x86/kernel/dumpstack.c` ARM处理入口:`arch/arm/kernel/traps.c` --- ### **典型日志特征** ``` [ 1234.567890] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [ 1234.567893] IP: [<ffffffff81234567>] do_something+0x123/0x456 [ 1234.567896] PGD 1234567 PUD 1234567 [ 1234.567898] Oops: 0000 [#1] SMP [ 1234.567900] CPU: 3 PID: 4567 Comm: process_name Tainted: G W OE 4.19.0-xx-generic [ 1234.567902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)... [ 1234.567905] RIP: 0010:[<ffffffff81234567>] [<ffffffff81234567>] do_something+0x123/0x456 [ 1234.567908] RSP: 0018:ffffc9000123ffd8 EFLAGS: 00010246 [ 1234.567910] RAX: 0000000000000000 RBX: ffff888123456789 RCX: 0000000000000001 ...(寄存器完整输出)... [ 1234.567923] Call Trace: [ 1234.567926] [<ffffffff8123abcd>] higher_function+0xef/0x234 [ 1234.567929] [<ffffffff8123def0>] syscall_handler+0x67/0x89 ...(调用栈追踪)... ``` --- ### **调试建议** 1. 检查 `dmesg` 输出完整日志 2. 使用 `objdump` 或 `addr2line` 解析地址信息 3. 配置 `CONFIG_DEBUG_INFO` 编译内核以获取符号详细信息 4. 通过 `crash` 工具分析vmcore文件(配合kdump使用) 该流程是内核稳定性的最后防线,开发者需要通过其输出信息定位根本原因。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员Android

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值