![[Android稳定性] 第047篇 [问题篇] Unexpected kernel BRK exception at EL1](https://halo-19274848.oss-cn-shanghai.aliyuncs.com/2025/06/halo_ityiau2.webp?x-oss-process=image/resize,w_800,m_lfit)
[Android稳定性] 第047篇 [问题篇] Unexpected kernel BRK exception at EL1
当前文章内容已隐藏,评论后可见。
![[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场?](https://halo-1259291793.cos.ap-shanghai.myqcloud.com/2025/06/a1dmnee.png?imageView2/0/w/800)
[Android稳定性] 第046篇 [方法篇] 如何使用trace32恢复AOP现场?
本文介绍了使用hansei工具解析AOP/RPM及使用trace32恢复AOP现场的方法。首先获取hansei工具,安装依赖库后执行工具,输入相关路径生成文件。然后进行恢复前的准备工作,包括下载T32脚本和准备相关文件。最后,通过执行aop_rpm_load.bat文件,选择正确的cmm文件开始恢复。
![[Android稳定性] 第044篇 [问题篇] Unable to handle kernel write to read-only memory at virtual address](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/24/11/4PSuNS.png)
[Android稳定性] 第044篇 [问题篇] Unable to handle kernel write to read-only memory at virtual address
在老化测试中,多台机器出现黑屏问题,主要现象为使用9-11版本时,27台机器中有25台因USB问题导致dump,且问题多出现在使用33瓦充电器时。通过LOG分析,问题出现在45次重启测试中。dmesg日志显示,问题源于内存异常踩踏,具体为操作了空指针地址的结构体成员。 根本原因分析表明,在dwc3_msm模块中,存在一个空指针赋值操作,导致数据写入异常地址。解决方案建议对涉及空指针的代码进行兼容性处理,并在gerrit上提交了相关代码修改。
![[Android稳定性] 第020篇 [方法篇] crash实战:手把手教你使用crash分析内核dump](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/25/1/cover_android_stability_020_d72a61900b5d80ca3b1a9b3aeea2d6c4.png)
[Android稳定性] 第020篇 [方法篇] crash实战:手把手教你使用crash分析内核dump
本文介绍了使用crash工具分析Linux内核崩溃(Kdump)的方法,重点针对手机领域。crash工具在处理大型dump文件时比trace32更加高效,因为它不会占用大量内存资源。文章还探讨了crash工具在恢复任务调用栈、查看局部变量值等方面的实用技巧,以及如何查找访问特定变量的线程。通过crash工具,开发者可以更有效地定位和解决内核崩溃问题,提高问题定位的效率。
![[Android稳定性] 第015篇 [问题篇] Unable to handle kernel NULL pointer dereference](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/25/1/cover_android_stability_015.png)
[Android稳定性] 第015篇 [问题篇] Unable to handle kernel NULL pointer dereference
系统出现死机,初步分析定位到问题为内核空指针引用,具体是在focaltech_spi模块的fts_power_usb_notifier_callback函数中。进一步通过trace32恢复现场发现,问题在于wq对象在函数执行过程中被销毁。根本原因是fts_data->ts_workqueue队列在fts_power_usb_notifier_callback执行过程中被销毁。
![[Android稳定性] 第010篇 [问题篇] 数组越界导致的内核panic](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/24/12/cover_android_stability_010.png)
[Android稳定性] 第010篇 [问题篇] 数组越界导致的内核panic
**摘要总结:** 服务器打包的daily版本在刷机后出现900E口死机问题。通过分析dmesg日志,发现程序在`fts_set_cur_value`函数处异常终止。进一步使用trace32工具恢复现场,确认是由于`touch_mode`数组越界导致的内存访问错误。该数组最大值被定义为15,但实际使用时传入了100,导致严重异常。
![[Android稳定性] 第009篇 [问题篇] 数组越界导致的内核panic](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/24/12/cover_android_stability_009.png)
[Android稳定性] 第009篇 [问题篇] 数组越界导致的内核panic
**问题现象**: 部分机器插着 USB 后出现死机。 **问题分析**: 通过 `dmesg` 和 `trace32` 分析,发现死机原因是 `power_operation_mode_show` 函数中 `typec_port` 结构体的 `pwr_opmode` 成员值错误(为负数),导致数组越界。 **解决方案**: 更新 charger 模块,修复对 `pwr_opmode` 的误判,确保其值为正数,避免数组越界。 **总结**: 本次问题是由 `typec_port` 结构体的 `pwr_opmode` 成员值错误导致,通过分析定位问题,并更新 charger 模块修复了问题。
![[Android稳定性] 第006篇 [问题篇] hungtask causing panic-死锁](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/24/12/cover_android_stability_006.png)
[Android稳定性] 第006篇 [问题篇] hungtask causing panic-死锁
本文讨论了一个系统问题现象,通过分析日志文件发现一个进程因等待锁而被阻塞120秒。通过使用`tace32`工具跟踪调用栈,发现存在一个三方的死锁情况,涉及进程`2848_9`、`crtc_commit:160`、`vendor.qti.came`和`kworker/u16:7`。文章详细展示了锁的持有者和调用栈信息,但未提供具体的解决方法。
![[Android稳定性] 第043篇 [问题篇] Unable to handle kernel NULL pointer dereference at virtual address](https://hexoimg.oss-cn-shanghai.aliyuncs.com/blog/24/11/SEkKvx.png)
[Android稳定性] 第043篇 [问题篇] Unable to handle kernel NULL pointer dereference at virtual address
在测试版本V816.0.24.8.26.UGUCNXM的稳定版挂测中,出现了大量的空指针引用错误。通过离线解析工具分析dump文件,发现问题的核心在于对NULL指针的引用。具体表现为在`mutex_lock`函数中尝试对一个来自`iocb->ki_filp->private_data`的NULL变量加锁,而这个变量是从`struct file`结构体中获取的。进一步检查发现,这与`/proc/hwinfo`节点有关,当尝试读取这个节点时,会导致手机死机。此节点是早期指纹需求所创建,目前已无实际用途,因此解决方案建议移除该节点。