用 addr2line 定位 OOPS 死机代码位置

最新推荐文章于 2025-06-18 17:50:43 发布
最新推荐文章于 2025-06-18 17:50:43 发布
阅读量1.4k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/fuyongming/article/details/50525198
本文详细介绍了如何通过分析Android内核日志中的函数地址信息，使用addr2line工具定位到具体崩溃文件及行号，从而帮助开发者深入理解并解决Android设备死机问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1. 一般 OOPS 死机时内核的 LOG kmsg 中会出现些函数地址等信息。

    

2. 执行 android代码包中的addr2line bin文件，比如文件 ./prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-addr2line

    (1). 如果不确定addr2line的具体名称，可以用 grep -nr "*addr2line*" 在android 代码包根目录下搜索。

    (2). 运行以下命令可以定义到死机在哪个文件的哪一行。

           ./prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-addr2line -e out/target/product/Q8145SA/vmlinux 0xc0201a1e
           显示结果

           /home/android/qualcomm/android/kernel/fs/jbd2/transaction.c:2048

          


Linux系统调试课：Oops 日志分析
内核笔记
04-11 1046
📢编写代码并不总是内核开发中最难的方面。 调试是真正的瓶颈，即使对于经验丰富的内核开发人员也是如此。 也就是说，大多数内核调试工具都是内核本身的一部分。 有时，内核通过称为Oops的消息帮助查找故障的起因。 然后，调试归结为分析消息。
linux 内核死机 堆栈,高通平台Linux kernel死机解题心得
weixin_29083649的博客
04-30 3370
1、前言1.1 目的能够借助相关调试工具，使用一般分析手段分析、定位解决项目过程中遇到的死机类系统稳定性问题，提升工作效率持续积累，拓宽知识深度和广度1.2 死机？指系统发生致命性异常导致主动或者被动进入系统完全不可用的状态，导致系统死机的问题原因有很多，排除硬件问题，还有这些大模块：Android、Linux kenrel、modem、TZ 等等，各个子系统都有可能导致系统死机重启，我们这里主要...
addr2line命令
热门推荐
06-13 7万+
在Linux下写C/C++程序的程序员，时常与Core Dump相见。在内存越界访问，收到不能处理的信号，除零等错误出现时，我们精心或不精心写就的程序就直接一命呜呼了，Core Dump是Linux仁慈地留下的程序的尸体，帮助程序员们解决了一个又一个问题。 有时配置不给力，Linux直接毁尸灭迹，没有了Core文件；又有时，刚好磁盘空间不足，Core文件写不下了。没有Core文件的时候，如何知道
addr2line查看死机代码的位置
Tony的专栏
07-10 5974
Addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。这种功能对于追踪死机地址转换成源码位置很有意义。      在调用 Addr2line 工具时，要使用 -e 选项来指定可执行映像是 test，通过使用 -f 选项，可以告诉工具输出函数名。 例如：addr2line -e test   0x12
使用addr2line工具排查报错堆栈
最新发布
qq_34341546的博客
06-18 244
内核出现pannic，空指针等问题是会出现堆栈打印，可以通过堆栈来定位具体的代码，这时候我们需要内核编译的 vmlinux，如果重新编译的话，符号表会更新，就无法定位。安卓对应的so库奔溃的话，也可以通过addr2line来定位问题点。
addr2line
weixin_42082222的博客
03-02 2586
binutils工具集之---addr2line addr2line用于得到程序指令地址所对应的函数，以及函数所在的源文件名和行号。 在不少嵌入式开发环境中，编译器的名称往往不是gcc，而是想arm-rtems-gcc这样的，对于这种命名形式的编译器，读者通常可以找到arm-rtems-addr2line ，arm-rtems-objdump等相应名称的工具，这是GNU工具集的一...
addr2line，可以根据一个地址打印出对应的代码行
weixin_30855099的博客
03-26 438
addr2line，输入一个地址，指定一个带-g编译的可执行程序，就可以打印出该地址对应的代码行。其实gdb也有这个功能，不过addr2line的好处是，很多时候，bug很难重现，我们手上只有一份crash log。这样就可以利用addr2line找到对应的代码行，很方便。前提条件是：1. 该可执行程序用-g编译，带调试信息（所谓调试信息就是代码和地址的一个对应关系的信息）。2. 如果cras...
rk3568死机调试
l00102795的博客
04-22 1734
spin_lock: 只关闭了抢占，未关闭中断，所以中断中如果也使用此锁则有可能导致死锁；spin_lock_irq: 关闭了抢占和中断，任何时候都是安全的。
Linux Kernel PANIC(三)--Soft Panic/Oops调试及实例分析
sunshineywz的博客
06-06 434
凡是非中断处理引发的模块崩溃都将导致 soft panic 在这种情况下, 驱动本身会崩溃, 但是还不至于让系统出现致命性失败, 因为它没有锁定中断处理例程. 导致 hard panic的原因同样对soft panic也有用(比如在运行时访问一个空指针). 1 驱动OOPS实例分析 1.1 导致 OOPS 的代码 模块代码, 有一处 NULL 指针异常 // kerneloops.c #include <linux/kernel.h> #include <linux/init.h>
定位内核模块crash的方法
xhz_1983的博客
06-14 3486
在内核模块开发过程中，常发生系统崩溃的现象，此时系统死机，无法定位和分析问题。 常见的定位方法是安装kdump-tools，kdump-tools可以把死机前的内核日志保存下来，以便开机后能分析上次死机的日志。 这里不介绍kdump-tools的安装配置方法，介绍如何分析crash日志，找到代码中出错的地方。 kdump-tools的crash日志一般放在/var/crash/出错时间/dm
binutils工具集之---addr2line
weixin_34211761的博客
02-23 545
  addr2line用于得到程序指令地址所对应的函数，以及函数所在的源文件名和行号。 在不少嵌入式开发环境中，编译器的名称往往不是gcc，而是想arm-rtems-gcc这样的，对于这种命名形式的编译器，读者通常可以找到arm-rtems-addr2line ，arm-rtems-objdump等相应名称的工具，这是GNU工具集的一种命名惯例。 本文并不是binutils工具集的完整参考手册...
Linux addr2line 命令
mayue_web的博客
02-09 7553
描述Linux下addr2line命令用于将程序指令地址转换为所对应的函数名、以及函数所在的源文件名和行号。当含有调试信息(-g)的执行程序出现crash时(core dumped)，可使用addr2line命令快速定位出错的位置。如果无法确定文件名或函数名，addr2line将在它们的位置打印两个问号；如果无法确定行号，addr2line将打印0或一个问号。查看使用和帮助手册参数说明-a --addresses：在函数名、文件和行号信息之前，显示地址，以十六进制形式。
Linux调试工具 | Addr2line
qq_43416206的博客
06-26 9473
通过addr2line的描述可知，在使用addr2line将地址转换为函数、文件名或行号时，其有两种使用方法：即对于可执行文件，addr2line后直接跟十六进制的地址值；对于可重定位对象文件，addr2line后直接跟十六进制的地址偏移量。从而实现正确输出需要的信息，否则会导致地址无法解析，输出??:0。提示：可通过file命令区分可执行文件与可重定位对象#输出executable,可知文件是可执行文件#输出relocatable，可知文件是可重定位对象。
【GNU】addr2line
W__winter的博客
11-17 572
addr2line是 GNU Binutils 工具集中的一个命令行工具，用于将程序中的地址转换为源代码中的文件名和行号。它在调试和问题定位中非常有用，尤其是在处理崩溃或 core dump 时。
SYSTEM_LAST_KMSG是什么log
03-19
<think>好的，我需要解释什么是SYSTEM_LAST_KMSG日志。首先，用户之前询问了关于设置Qsync min fps的问题，现在转向系统日志相关的SYSTEM_LAST_KMSG。我需要确保回答准确，结构清晰，符合之前的格式要求。 首先，SYSTEM_LAST_KMSG是什么？根据我的知识，这是Android系统中的一种日志文件，记录内核最后一次运行的信息，尤其是在系统崩溃或意外重启时。需要明确它的作用、存储位置、内容结构以及应用场景。 接下来要考虑用户可能的背景。他们可能遇到了系统崩溃或启动问题，需要分析这个日志来排查原因。因此，回答中需要包含如何获取该日志、如何分析，以及常见问题的解决方案。 需要验证信息是否正确。比如，SYSTEM_LAST_KMSG是否真的位于/proc/last_kmsg，是否在重启后会被清除？另外，不同Android版本是否有差异？可能需要确认这些细节，避免给出错误信息。 结构方面，按照之前的总结格式，分点解析，核心概念、内容结构、应用场景、获取方法、分析步骤、注意事项、示例和总结。每个部分要简明扼要，帮助用户逐步理解。 还要注意用户可能的误区，比如与last_kmsg的区别，或者与其他日志如dmesg的关系。需要明确区分，避免混淆。 最后，确保语言口语化，避免技术术语过多，同时保持专业性。检查是否符合LaTeX格式要求，行内公式用$...$，独立公式用$$...$$，但在这个问题中可能用不上数学公式，所以主要注意中文字符和标点。 现在开始组织内容，确保每个部分逻辑清晰，覆盖关键点，并且准确无误。</think>### **关于 `SYSTEM_LAST_KMSG` 日志的技术总结** --- #### **1. 核心定义** `SYSTEM_LAST_KMSG` 是 **Android 系统**中记录内核（Kernel）最后一次运行信息的日志文件，通常保存了系统崩溃（Crash）、意外重启（Unexpected Reboot）或死机（Freeze）前的内核级事件和错误信息。其作用类似于 Linux 系统的 `dmesg` 日志，但专门用于调试系统异常终止问题。 --- #### **2. 日志内容与结构** - **存储位置**： 一般位于 `/proc/last_kmsg`，但需 root 权限访问（部分设备可能路径不同，如 `/sys/fs/pstore/console-ramoops`）。 - **关键信息**： - **内核崩溃原因**：如空指针访问（`NULL pointer dereference`）、内存溢出（`Out-of-Memory, OOM`）、硬件错误（Hardware Fault）等。 - **堆栈跟踪（Stack Trace）**：显示崩溃时函数调用链，帮助定位代码问题。 - **硬件状态**：CPU 寄存器值、进程状态（Process States）、中断记录（IRQ Logs）等。 - **示例片段**： ```plaintext [ 1234.567890] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 1234.567891] PC is at faulty_function+0x123/0x456 [ 1234.567892] LR is at some_caller+0x789/0xabc ``` --- #### **3. 应用场景** - **系统崩溃分析**：设备频繁重启或无法开机时，通过该日志诊断内核级故障。 - **驱动调试**：排查第三方硬件驱动（如摄像头、传感器）与内核的兼容性问题。 - **定制 ROM 开发**：修复系统底层代码（如电源管理、内存分配）的稳定性问题。 --- #### **4. 获取方法** 1. **通过 ADB 提取**（需 USB 调试开启）： ```bash adb shell su -c "cat /proc/last_kmsg > /sdcard/last_kmsg.txt" adb pull /sdcard/last_kmsg.txt ``` 2. **直接读取文件**：使用 Root Explorer 等工具访问 `/proc/last_kmsg`。 3. **注意限制**： - 若系统正常重启，该日志可能被覆盖或清除。 - 部分设备需在崩溃后立即获取，否则日志会丢失。 --- #### **5. 分析步骤** 1. **定位崩溃时间戳**：查找日志末尾的 `[timestamp]` 确定崩溃发生时刻。 2. **识别错误类型**： - **常见关键词**：`panic`（内核崩溃）、`Oops`（严重错误）、`BUG:`（内核断言失败）。 3. **追踪代码路径**： - 根据 `PC`（程序计数器）和 `LR`（链接寄存器）地址，结合内核符号表（`vmlinux`）或反汇编工具定位问题函数。 4. **检查硬件状态**： - 分析寄存器值（如 `R0-R15`）是否异常，排查内存访问越界或硬件寄存器配置错误。 --- #### **6. 典型问题与解决方案** - **问题1：日志为空或不存在** - **原因**：系统正常关闭、日志被覆盖、设备未启用内核日志缓存。 - **解决**：启用 `pstore` 或 `ramoops` 模块持久化保存日志。 - **问题2：频繁内核空指针崩溃** - **原因**：驱动未初始化变量、内存释放后重复使用（Use-After-Free）。 - **解决**：检查驱动代码的指针有效性，使用 `kasan`（内核地址消毒剂）调试内存错误。 - **问题3：硬件中断冲突** - **现象**：日志中出现 `IRQ handler type mismatch`。 - **解决**：调整设备树（Device Tree）中的中断分配，避免共享中断线。 --- #### **7. 注意事项** - **安全性**：直接操作内核日志需 root 权限，不当修改可能导致系统变砖。 - **兼容性**：不同 Android 版本或芯片平台（如高通、MTK）的日志格式可能差异较大。 - **工具依赖**：推荐使用 `crash` 工具、`addr2line` 或 `GDB` 解析符号和地址。 --- #### **8. 总结** `SYSTEM_LAST_KMSG` 是诊断 Android 系统内核级故障的关键日志，需结合代码分析与硬件状态解读。开发者和高级用户可通过其定位驱动错误、内存泄漏或硬件兼容性问题，但操作时需谨慎避免进一步系统损坏。若日志分析困难，建议提交至芯片厂商或社区论坛寻求协助。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值