Android5.0L中SensorService crash导致的systemserver重启问题分析

一、初步分析结论

sensorservice多线程机制存在问题,导致在disable accel sensor并释放相应内存和数据之后,

有很小的概率发生继续读取到未处理完的sensor事件,从而继续使用相应的内存和数据,

并且没有做相应的防御保护措施,最终引起指针地址操作错误。

二、解决方案

1、首先在可能发生错误的地方做好防御保护措施

2、对多线程进行同步,对于临界变量的操作都放置到临界区中,使用锁来保护。

三、具体分析过程

log中显示打出accel sensor被disable的信息,然后接着1ms sensorservice就crash。

Disable accel sensor会先注销listener并释放相应内存,然后再调用具体的sensor的hal去disable,具体代码如下:

注销listener时会释放内存和数据:

真正发生地址操作失败的代码并没有进行相应的判空保护,如果781行得到的是0,那么783的item也是0,它的成员ctx相对偏移是8,在对8进行寻址和成员操作时就出现了内存错误,因为8不是一个有效的数据对象地址,具体如下:

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-15 13:17:09

Android5.0L中SensorService crash导致的systemserver重启问题分析的相关文章

Android5.0L因SystemUI ANR导致的黑屏问题分析

一.问题现象 1.用户直观看到的现象是黑屏. 2.出问题时StatusBar.NavigationBar和墙纸消失. 3.大部分发生在FOTA重启之后,出现概率很低. Platform:MSM8916 Android版本:5.0.2L BuildType:user 系统软件版本:VA6V+L5V0 系统RAM:1GB 参考机行为: 1.5.0L的Nexus4和5.1L的Nexus5都没有重现此问题. 二.解决方案 通过初步分析.深入分析(具体分析过程.关键代码和log在下面会附上)我们清楚的知道

Android5.0L下因sensorservice crash导致systemserver重启的另外一种场景分析

一.出问题的场景 1.Sensorservice线程正在处理compass sensor事件的过程中,检查了一次buffer的指针的有效性,并在稍后会传递到AKM获取数据的函数接口中使用 2.Sensorservice线程所在进程的负责跨进程通信的Binder线程在sensorservice线程检查buffer指针之后没有真正使用之前, 收到了disable compass sensor的请求,从log中可以看到compass  sensor先是被disable,disable的同时会free上

MTK Sensor越界导致的系统重启问题分析报告

[NE现场] 打开12306应用后做一些操作,和容易出现系统重启.dropbox中有好多system_server的tombstone文件: ./[email protected]1449222028760.txt:12:pid: 10466, tid: 10493, name: android.bg >>> system_server <<< ./[email protected]1449455808867.txt:12:pid: 5992, tid: 6053, n

Android5 Zygote 与 SystemServer 启动流程分析

Android5 Zygote 与 SystemServer 启动流程分析 Android5 Zygote 与 SystemServer 启动流程分析 前言 zygote 进程 解析 zygoterc 启动 SystemServer 执行 ZygoteInitrunSelectLoop SystemServer 启动过程 Zygote 的 fork 本地方法分析 forkSystemServer ZygoteHookspreFork 创建 system_server 进程 ZygoteHooks

iOS:项目中疑难Crash问题集锦

项目中疑难Crash问题集锦 iOS App运行中遇到Crash的情况相信大家都遇到过,开发和者测试中遇到了可能很方便的办法就是直接拿着设备连接一下,然后使用Xcode自带的工具就可以解析出Crash地址了.对于线上App运行时的Crash收集也有很多好用的第三方工具,具有代表性的就是Crashlytics,通过打包时上传dSYM文件,收集到的Crash就可以解析为可读的格式了. 尽管Crashlytics功能已经很强大了,统计出来的Crash信息也足够详细,还是会有一些难缠的问题,例如程序直接

项目中疑难Crash问题集锦

iOS App运行中遇到Crash的情况相信大家都遇到过,开发和者测试中遇到了可能很方便的办法就是直接拿着设备连接一下,然后使用Xcode自带的工具就可以解析出Crash地址了.对于线上App运行时的Crash收集也有很多好用的第三方工具,具有代表性的就是Crashlytics,通过打包时上传dSYM文件,收集到的Crash就可以解析为可读的格式了. 尽管Crashlytics功能已经很强大了,统计出来的Crash信息也足够详细,还是会有一些难缠的问题,例如程序直接就挂在main函数中,剩下的就

服务器中了病毒导致交换机无法正常运行

服务器:联想万全 问题:无法访问服务器上的网站,网断断断续续,最终导致服务器宕机. 原因:服务器中了病毒,导致IIS无法运行的同时,服务器也宕机. 解决方式: 首先,分析原因,IIS发布的所有网站无法运行,恢复初始IIS发布网站还是未成功.通过与团队技术人员沟通,最终确定操作系统中了病毒. 其次,恢复操作系统,恢复的过程中没有采用光驱安装,原因是光驱已损坏:用U盘恢复系统的时间失败,原因是从网上下了一个没有经过测试就使用的系统镜像,结果不兼容,导致安装失败: 再次,通过恢复先前的备份系统文件,文

[转载]DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子2

(转载于breaksoftware的csdn博客) 本文介绍使用Windbg去验证<DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子>中的结论,调试对象是文中刚开始那个例子. 1 g 让程序运行起来 2 ctrl+break 中断程序 3 ~ 查看线程数 其实该程序自己运行起来的线程只有ID为0.TID为afc的线程.18c4线程是我们在windbg中输入ctrl+break,导致windbg在我们调试的进程中插入的一个中断线程.以后我们看到是这个线程的操作

[Android学习笔记]ListView中含有Button导致无法响应onItemClick回调的解决办法

转自:http://www.cnblogs.com/eyu8874521/archive/2012/10/17/2727882.html 问题描述: 当ListView的Item中的控件只是一些展示类控件时(比如TextView),注册ListView的监听setOnItemClickListener之后,当点击Item时候会触发onItemClick回调. 但是,当Item中存在Button(继承于Button)的控件时,onItemClick回调不会被触发. 解决方案: 在Item的布局文件