首页 > 代码库 > MTK Sensor越界导致的系统重启问题分析报告
MTK Sensor越界导致的系统重启问题分析报告
【NE现场】
打开12306应用后做一些操作，和容易出现系统重启。dropbox中有好多system_server的tombstone文件：
./SYSTEM_TOMBSTONE@1449222028760.txt:12:pid: 10466, tid: 10493, name: android.bg >>> system_server <<< ./SYSTEM_TOMBSTONE@1449455808867.txt:12:pid: 5992, tid: 6053, name: AlarmManager >>> system_server <<< ./SYSTEM_TOMBSTONE@1449222028730.txt:12:pid: 10466, tid: 10494, name: ActivityManager >>> system_server <<< ./SYSTEM_TOMBSTONE@1449455808843.txt:12:pid: 5992, tid: 6014, name: SensorService >>> system_server <<< ./SYSTEM_TOMBSTONE@1449457509508.txt:12:pid: 11012, tid: 11887, name: Binder_E >>> system_server <<< ./SYSTEM_TOMBSTONE@1449229865122.txt:12:pid: 18238, tid: 18260, name: SensorService >>> system_server <<<
可以看到每次crash的线程都不一样！甚至backtrace也不一样:
@SYSTEM_TOMBSTONE@1449222028760.txt
pid: 10466, tid: 10493, name: android.bg >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa00000070
...
backtrace:
#00 pc 0000000000029f70 /system/lib64/libbinder.so (android::IPCThreadState::flushCommands()+4)
#01 pc 0000000000009c60 /data/dalvik-cache/arm64/system@framework@boot.oat
@SYSTEM_TOMBSTONE@1449455808867.txt
pid: 5992, tid: 6053, name: AlarmManager >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x553d89e3c0
...
backtrace:
#00 pc 0000000000030bc4 /system/lib64/libbinder.so (int android::Parcel::writeAligned<int>(int)+80)
#01 pc 00000000000d3e0c /system/lib64/libandroid_runtime.so
#02 pc 0000000000109630 /data/dalvik-cache/arm64/system@framework@boot.oat
@SYSTEM_TOMBSTONE@1449222028730.txt
pid: 10466, tid: 10494, name: ActivityManager >>> system_server <<<
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x7f0000000a
...
backtrace:
#00 pc 0000007f0000000a <unknown>
@SYSTEM_TOMBSTONE@1449455808843.txt
pid: 5992, tid: 6014, name: SensorService >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa00000068
backtrace:
#00 pc 000000000000f508 /system/lib64/libsensorservice.so
#01 pc 0000000000010e90 /system/lib64/libsensorservice.so
#02 pc 00000000000179c0 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+188)
#03 pc 000000000009277c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+96)
#04 pc 0000000000017224 /system/lib64/libutils.so
#05 pc 000000000001cbb0 /system/lib64/libc.so (__pthread_start(void*)+52) #06 pc 0000000000019044 /system/lib64/libc.so (__start_thread+16)
@SYSTEM_TOMBSTONE@1449457509508.txt
pid: 11012, tid: 11887, name: Binder_E >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
backtrace:
#00 pc 0000000000014070 /system/lib64/libutils.so (android::RefBase::decStrong(void const*) const+236)
#01 pc 000000000002f694 /system/lib64/libbinder.so (android::Parcel::releaseObjects()+84)
#02 pc 000000000002f6e8 /system/lib64/libbinder.so (android::Parcel::freeDataNoInit()+60)
#03 pc 000000000002f744 /system/lib64/libbinder.so (android::Parcel::ipcSetDataReference(unsigned char const*, unsigned long, unsigned long long const*, unsigned long, void (*)(android::Parcel*, unsigned char const*, unsigned long, unsigned long long const*, unsigned long, void*), void*)+40)
#04 pc 000000000002a44c /system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+700)
#05 pc 000000000002a6c8 /system/lib64/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+92)
#06 pc 000000000002a73c /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+76)
#07 pc 0000000000031d68 /system/lib64/libbinder.so
#08 pc 00000000000179c0 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+188)
#09 pc 000000000009277c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+96)
#10 pc 0000000000017224 /system/lib64/libutils.so
#11 pc 000000000001cbb0 /system/lib64/libc.so (__pthread_start(void*)+52)
#12 pc 0000000000019044 /system/lib64/libc.so (__start_thread+16)
@SYSTEM_TOMBSTONE@1449229865122.txt
pid: 18238, tid: 18260, name: SensorService >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7f3d798d38
backtrace:
#00 pc 000000000000dbc0 /system/lib64/libsensorservice.so
#01 pc 000000000000ed44 /system/lib64/libsensorservice.so
#02 pc 000000000000f3a8 /system/lib64/libsensorservice.so
#03 pc 0000000000011078 /system/lib64/libsensorservice.so
#04 pc 00000000000179c0 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+188)
#05 pc 000000000009277c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+96)
#06 pc 0000000000017224 /system/lib64/libutils.so
#07 pc 000000000001cbb0 /system/lib64/libc.so (__pthread_start(void*)+52)
#08 pc 0000000000019044 /system/lib64/libc.so (__start_thread+16)
这种backtrace都不一样的问题很可能就是内存问题了，所谓内存问题指的就是野指针或内存越界。
【问题分析】
分析内存问题的第一步就是排查NE现场寄存器指向的内存值附近有没有规律。比如：
@SYSTEM_TOMBSTONE@1449222028760.txt
pid: 10466, tid: 10493, name: android.bg >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa00000070
x0 000000557e996710 x1 0000000a00000068 x2 0000007f79c31ba0 x3 0000000000000000
x4 000000006fc46a80 x5 0000000000000001 x6 0000000000000000 x7 000000557e4f527c
x8 0000000000000000 x9 000000557e4f5278 x10 0000000000000000 x11 0000000000000000
x12 0000000000000000 x13 0000000000430000 x14 0000000000550000 x15 0000000000430000
x16 0000007f8f640320 x17 0000007f8eff4f6c x18 0000007f8c1d0470 x19 000000000000000a
x20 0000007f8f590e9c x21 000000557e9b14d0 x22 000000001354bf40 x23 000000006fdf61f0
x24 0000007f79c31b20 x25 0000000012da2040 x26 0000000000000000 x27 00000000000f52be
x28 0000000000000000 x29 0000000000358c82 x30 0000000072639c64
sp 0000007f79c31680 pc 0000007f8eff4f70 pstate 0000000080000000
backtrace:
#00 pc 0000000000029f70 /system/lib64/libbinder.so (android::IPCThreadState::flushCommands()+4)
#01 pc 0000000000009c60 /data/dalvik-cache/arm64/system@framework@boot.oat
查看#00层代码：
$ aarch64-linux-android-objdump -D symbols/system/lib64/libbinder.so 0000000000029f6c <_ZN7android14IPCThreadState13flushCommandsEv>: 29f6c: f9400001 ldr x1, [x0] => 29f70: b9400822 ldr w2, [x1,#8] 29f74: 6b1f005f cmp w2, wzr 29f78: 5400006d b.le 29f84 <_ZN7android14IPCThreadState13flushCommandsEv+0x18> 29f7c: 52800001 mov w1, #0x0 // #0 29f80: 17ffd9ec b 20730 <_ZN7android14IPCThreadState14talkWithDriverEb@plt> 29f84: d65f03c0 ret
x1值是x0地址中取来的，0x0000000a00000068显然不是一个合法地址。可能是x0地址被覆盖了。
查看x0附近的内存值：
memory near x0:
000000557e9966f0 0000007f8f01e748 0000000000000000
000000557e996700 0000000000000000 0000000000000007
000000557e996710 0000000a00000068 0000007f0000000a
000000557e996720 00000438234cda2a 3de6de183dc20f78
000000557e996730 000000003d9e2680 0000000000000008
000000557e996740 0000000000000000 0000000000000000
000000557e996750 0000000000000000 0000000000000000
000000557e996760 0000000000010001 0000000000000000
000000557e996770 000000557e996840 0000000a00000068
000000557e996780 000000550000000a 000004382647caaa
000000557e996790 3de6de183dc20f78 000000003d9e2680
000000557e9967a0 0000000000000000 0000000000000000
000000557e9967b0 0000000000000000 0000000000000000
000000557e9967c0 0000007f8e010001 0000000000000000
000000557e9967d0 0000000000000000 000028e200000040
000000557e9967e0 0000000a00000068 000000550000000a
发现一个明显的规律：
0x0000000a00000068出现了多次，而且间隔都是13*8=104字节，每个块的结构都很相似，很可能这个数据是个结构体数组。
继续分析下一个tombstone:
@SYSTEM_TOMBSTONE@1449455808867.txt
pid: 5992, tid: 6053, name: AlarmManager >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x553d89e3c0
x0 00000055837f4dc0 x1 0000000000000004 x2 0000000000000440 x3 0000000000020000
x4 0000000000000444 x5 000000553d89df80 x6 0000000000000000 x7 000000558336b27c
x8 0000000000000000 x9 000000558336b278 x10 0000000000000000 x11 0000000000000000
x12 0000000000000000 x13 0000000000430000 x14 0000000000550000 x15 0000000000430000
x16 0000007f7e502478 x17 0000007f7e4dbb74 x18 0000007f7b6b0470 x19 00000055837f4dc0
x20 000000008080005c x21 0000005583838590 x22 000000008080005c x23 000000006fd15b08
x24 000000008080005c x25 000000003000003a x26 0000000012d5fe80 x27 0000000012c47400
x28 000000000000005c x29 0000007f68090bd0 x30 0000007f7ea66e10
sp 0000007f68090bd0 pc 0000007f7e4dbbc4 pstate 0000000080000000
backtrace:
#00 pc 0000000000030bc4 /system/lib64/libbinder.so (int android::Parcel::writeAligned<int>(int)+80)
#01 pc 00000000000d3e0c /system/lib64/libandroid_runtime.so
#02 pc 0000000000109630 /data/dalvik-cache/arm64/system@framework@boot.oat
查看#00层代码：
$ aarch64-linux-android-objdump -D symbols/system/lib64/libbinder.so 0000000000030b74 <_ZN7android6Parcel12writeAlignedIiEEiT_>: 30b74: a9be7bfd stp x29, x30, [sp,#-32]! 30b78: 910003fd mov x29, sp 30b7c: a90153f3 stp x19, x20, [sp,#16] 30b80: aa0003f3 mov x19, x0 30b84: 2a0103f4 mov w20, w1 30b88: f9401002 ldr x2, [x0,#32] 30b8c: f9400c03 ldr x3, [x0,#24] 30b90: 91001044 add x4, x2, #0x4 30b94: eb03009f cmp x4, x3 30b98: 54000109 b.ls 30bb8 <_ZN7android6Parcel12writeAlignedIiEEiT_+0x44> 30b9c: d2800081 mov x1, #0x4 // #4 30ba0: 97ffbbe4 bl 1fb30 <_ZN7android6Parcel8growDataEm@plt> 30ba4: 34000080 cbz w0, 30bb4 <_ZN7android6Parcel12writeAlignedIiEEiT_+0x40> 30ba8: a94153f3 ldp x19, x20, [sp,#16] 30bac: a8c27bfd ldp x29, x30, [sp],#32 30bb0: d65f03c0 ret 30bb4: f9401262 ldr x2, [x19,#32] 30bb8: f9400665 ldr x5, [x19,#8] 30bbc: aa1303e0 mov x0, x19 30bc0: d2800081 mov x1, #0x4 // #4 => 30bc4: b82268b4 str w20, [x5,x2] 30bc8: a94153f3 ldp x19, x20, [sp,#16] 30bcc: a8c27bfd ldp x29, x30, [sp],#32 30bd0: 17ffbf3c b 208c0 <_ZN7android6Parcel11finishWriteEm@plt>
NE的原因是x5值非法，而x5是从x19中取出来的，查看x19值：
memory near x19:
00000055837f4da0 0000000200000004 0000000a00000068
00000055837f4db0 000000550000000a 0000015263c04a64
00000055837f4dc0 3d5762703e10ca1c 000000553d89df80
00000055837f4dd0 0000000000000440 0000000000020000
00000055837f4de0 0000000000000440 0000000000000000
00000055837f4df0 0000000000000000 0000000000000000
00000055837f4e00 0000000000000000 0000000000010001
00000055837f4e10 0000000a00000068 000000550000000a
00000055837f4e20 0000015266bb3ae4 3d5762703e10ca1c
00000055837f4e30 0000007f3d89df80 000000558379c020
00000055837f4e40 000000558382ea70 0000656c62617300
00000055837f4e50 0000000000000000 00000000000000d3
00000055837f4e60 0000007f7eb1dc28 0000000000000000
00000055837f4e70 0000007f7c8f2348 0000000a00000068
00000055837f4e80 000000020000000a 0000015269b62b64
00000055837f4e90 3d5762703e10ca1c 000000003d89df80
被破坏的现场合前面一个现场几乎相同！
后面几个就直接在tombstone里搜索0000000a00000068，发现每一个都是有0000000a00000068， 且间隔都是104字节。
@SYSTEM_TOMBSTONE@1449222028730.txt
memory near x1:
000000557e996a50 0000000a00000068 000000000000000a
000000557e996a60 000004383b245e2a 3de6de183dc20f78
000000557e996a70 000000003d9e2680 0000000000000000
000000557e996a80 0000000000000007 00000000000f8327
000000557e996a90 0000007f89b05070 0000000000000000
000000557e996aa0 0000007f79a26000 0000007f00000000
000000557e996ab0 0000000000000000 0000000a00000068
000000557e996ac0 000000000000000a 000004383e1f4eaa
000000557e996ad0 3de6de183dc20f78 000000003d9e2680
000000557e996ae0 0000000012d94a90 0000000000000000
000000557e996af0 0000007f79a24000 0000000000103000
000000557e996b00 0000000000000000 0000000000000000
000000557e996b10 0000000000000000 0000000000000000
000000557e996b20 0000000a00000068 000000000000000a
000000557e996b30 00000438411a3f2a 3de6de183dc20f78
000000557e996b40 000000553d9e2680 000000557e915720
@SYSTEM_TOMBSTONE@1449455808843.txt
memory near x9:
000000558380c828 000000007614b620 7461003b72656e65
000000558380c838 0000000000000000 000000558380d530
000000558380c848 0000000a00000068 000000550000000a
000000558380c858 0000015d3d53dc64 3d5762703e10ca1c
000000558380c868 000000003d89df80 0000007f7c8f1fd8
000000558380c878 000000020000008d 0000000200000004
000000558380c888 00000000753a770c 0000000000000000
000000558380c898 0000000000000234 0000000000000000
000000558380c8a8 0000000000000000 0000000000000000
000000558380c8b8 0000000000000000 0000007f7c7f9860
000000558380c8c8 0000000000000101 00000000753a770c
000000558380c8d8 0000000000000000 0000000000000234
000000558380c8e8 0000000000000000 0000000000000000
000000558380c8f8 0000000000000000 000000558337a320
000000558380c908 0000000000000001 00000000d6000025
000000558380c918 0000000000000000 0000000000000000
@SYSTEM_TOMBSTONE@1449457509508.txt
memory near x19:
0000005594c52190 3d7e9cb83e33b9be 000000003d567500
0000005594c521a0 0000000000000000 0000000000000000
0000005594c521b0 0000000100000000 0000000000000000
0000005594c521c0 0000000000000000 0000000000000160
0000005594c521d0 0000000000000000 0000007f9d76b470
0000005594c521e0 0000000a00000068 000000110000000a
0000005594c521f0 000001d7e54f0ade 3d7e9cb83e33b9be
0000005594c52200 000000003d567500 0000000000000000
0000005594c52210 0000000000000000 0000005594bc6700
0000005594c52220 0000000000000000 0000000000000000
0000005594c52230 0000000000000081 0000005500000000
0000005594c52240 0000007f9e6baf60 0000000a00000068
0000005594c52250 0000007f0000000a 000001d7e849fb5e
0000005594c52260 3d7e9cb83e33b9be 0000007f3d567500
0000005594c52270 0000007f9e6baf00 0000000000110000
0000005594c52280 0000000000000000 0000000000000000
@SYSTEM_TOMBSTONE@1449229865122.txt
memory near x0:
0000005599644de0 0000000a00000068 000000550000000a
0000005599644df0 0000066c78c6a111 3d8b65883e0ed844
0000005599644e00 0000007f3d798d00 0000005599648310
0000005599644e10 0000005599644ca8 0000005599644cd8
0000005599644e20 0000000400000004 420ba3d700000000
0000005599644e30 40c333333c2f4f0e 0000000300000000
0000005599644e40 0000000000000000 0000000a00000068
0000005599644e50 000000550000000a 0000066c7bc19191
0000005599644e60 3d8b65883e0ed844 0000007f3d798d00
0000005599644e70 0000000000000080 0000000000000053
0000005599644e80 0000000000000051 0000000000000046
0000005599644e90 0000005599644ed0 0000007f97c18000
0000005599644ea0 0000000000000000 0000007f97c18000
0000005599644eb0 0000000a00000068 000000010000000a
0000005599644ec0 0000066c7ebc8211 3d8b65883e0ed844
0000005599644ed0 61642f613d798d00 6361632d6b69766c
至此基本上能确定就是这个大小为104字节，带有0x0000000a00000068这个pattern的结构体数组覆盖正常内存导致的。
下一步就是要确定这个0x0000000a00000068属于哪个结构体。
从tombstone的maps数据中可以知道每次出现问题的地址都是堆内存，因此覆盖和被覆盖的内存也应该都是malloc出来的。
@SYSTEM_TOMBSTONE@1449229865122.txt
...
00000055996ba000-0000005599d24fff rw- 6729728 [heap]
...
现在我们可以用hook工具hook free函数，然后再free时判断内存里是否有0000000a00000068，如果有这个pattern就打印调用栈。
代码如下：
#if defined(__aarch64__) extern "C" void free(void* p); extern "C" void inject_free(void* p) { if(p != NULL) { size_t* head = (size_t*)((char*)p-sizeof(size_t)); //这里通过heap chunk的head信息得出指针的大小 size_t size = *head & ~7,i=0; int* p_int = (int*)p; while(i < size/sizeof(int)) { if(*(p_int+i)== 0x00000068 && *(p_int+i+1)==0x0000000a ) { //这里判断内存中是否有pattern LOGD("size=%llu",size); size_t j = 0; while(j < size/sizeof(int)) { LOGD("p_int[%d]=%08x",j,*(p_int+j)); j++; } dump_java_stack(); dump_native_stack(); } i++; } } free(p); //这里再调用真正的free } #endif
打开12306复现问题，发现退出应用时，有如下日志：
# logcat |grep INJECT D/INJECT ( 912): size=102352 D/INJECT ( 912): p_int[0]=00000068 D/INJECT ( 912): p_int[1]=0000000a D/INJECT ( 912): p_int[2]=0000000a D/INJECT ( 912): p_int[3]=00000055 D/INJECT ( 912): p_int[4]=0eaa916c D/INJECT ( 912): p_int[5]=0000493a D/INJECT ( 912): p_int[6]=bdaadb00 D/INJECT ( 912): p_int[7]=bcd10f00 D/INJECT ( 912): p_int[8]=be057140 D/INJECT ( 912): p_int[9]=00000000 ... D/INJECT ( 912): p_int[25586]=00007041 D/INJECT ( 912): p_int[25587]=00000000 D/INJECT ( 912): #00 pc 0000000000000a24 /system/lib64/libinjectapis.so (inject_free+236) D/INJECT ( 912): #01 pc 000000000000fc28 /system/lib64/libsensorservice.so D/INJECT ( 912): #02 pc 000000000000fcf4 /system/lib64/libsensorservice.so D/INJECT ( 912): #03 pc 00000000000141b4 /system/lib64/libutils.so (android::RefBase::decStrong(void const*) const+560) D/INJECT ( 912): #04 pc 0000000000029858 /system/lib64/libbinder.so (android::IPCThreadState::processPendingDerefs()+140) D/INJECT ( 912): #05 pc 000000000002a734 /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+68) D/INJECT ( 912): #06 pc 0000000000031d68 /system/lib64/libbinder.so D/INJECT ( 912): #07 pc 00000000000179c0 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+188) D/INJECT ( 912): #08 pc 000000000009277c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+96) D/INJECT ( 912): #09 pc 0000000000017224 /system/lib64/libutils.so D/INJECT ( 912): #10 pc 000000000001cbb0 /system/lib64/libc.so (__pthread_start(void*)+52) D/INJECT ( 912): #11 pc 0000000000019044 /system/lib64/libc.so (__start_thread+16)
看来是抓到这个罪魁祸首了！
用addr2line看看是哪个文件哪一行：
$ aarch64-linux-android-addr2line -f -e symbols/system/lib64/libsensorservice.so fc28 _ZN7android13SensorService21SensorEventConnectionD1Ev /home/mi/disk/2-v6-l-hermes-dev/frameworks/native/services/sensorservice/SensorService.cpp:1021
@frameworks/native/services/sensorservice/SensorService.cpp
SensorService::SensorEventConnection::~SensorEventConnection() { ALOGD_IF(DEBUG_CONNECTIONS, "~SensorEventConnection(%p)", this); mService->cleanupConnection(this); if (mEventCache != NULL) { delete mEventCache; } }
就是delete mEventCache语句释放带有0000000a00000068的内存，看看它是被创建的代码：
@frameworks/native/services/sensorservice/SensorService.cpp status_t SensorService::SensorEventConnection::sendEvents( sensors_event_t const* buffer, size_t numEvents, sensors_event_t* scratch, SensorEventConnection const * const * mapFlushEventsToConnections) { ... mEventCache = new sensors_event_t[mMaxCacheSize];
这个mEventCache确实是个结构体数组指针。这个new sensors_event_t的定义如下：
@hardware/libhardware/include/hardware/sensors.h typedef struct sensors_event_t { /* must be sizeof(struct sensors_event_t) */ int32_t version; /* sensor identifier */ int32_t sensor; /* sensor type */ int32_t type; /* reserved */ int32_t reserved0; /* time is in nanosecond */ int64_t timestamp; union { ... } /* Reserved flags for internal use. Set to zero. */ uint32_t flags; uint32_t reserved1[3]; } sensors_event_t;
0x0000000a00000068中的68就是version，也就是这个结构体的大小，0x68=104字节，完全符合pattern。
接下来就是排查mEventCache，首先排除野指针，因为复现问题前并没有打印free的log，那只能是内存越界了。
再SensorService.cpp中所有能写mEventCache的地方加了log，发现复现问题时也没有相关log打印出来。
又在原生机器试了一下，发现原生没有这个问题，所以可能不是framework的SensorService代码问题。
sensors_event_t是hardware的头文件里定义的，由次可以判断sensors_event_t这个数据应该是hardware层给framework的buffer里写的。
有是只有MTk机器上出现的问题，所以问题很可能是出在hardware层。
在vendor下搜索sensors_event_t，会发现有很多sensor的实现，不太好定位问题：
vendor$ cgrep sensors_event_t ./mediatek/proprietary/hardware/sensor/InPocket.h:45: sensors_event_t mPendingEvent; ./mediatek/proprietary/hardware/sensor/InPocket.h:50: virtual int readEvents(sensors_event_t* data, int count); ./mediatek/proprietary/hardware/sensor/Activity.cpp:45: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/Activity.cpp:225:int ActivitySensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/Shake.cpp:46: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/Shake.cpp:216:int ShakeSensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/PickUp.h:45: sensors_event_t mPendingEvent; ./mediatek/proprietary/hardware/sensor/PickUp.h:50: virtual int readEvents(sensors_event_t* data, int count); ./mediatek/proprietary/hardware/sensor/Hwmsen.h:96: sensors_event_t mPendingEvents[numSensors]; ... ./mediatek/proprietary/hardware/sensor/PickUp.cpp:215:int PickUpSensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/GlanceGesture.cpp:47: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/GlanceGesture.cpp:208:int GlanceGestureSensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/FaceDown.cpp:44: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/FaceDown.cpp:213:int FaceDownSensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/AmbienteLight.cpp:62: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/AmbienteLight.cpp:250:int AmbiLightSensor::readEvents(sensors_event_t* data, int count) ./mediatek/proprietary/hardware/sensor/HeartRate.h:44: sensors_event_t mPendingEvent; ./mediatek/proprietary/hardware/sensor/HeartRate.h:49: virtual int readEvents(sensors_event_t* data, int count); ./mediatek/proprietary/hardware/sensor/Proximity.h:64: sensors_event_t mPendingEvent; ./mediatek/proprietary/hardware/sensor/Proximity.h:69: virtual int readEvents(sensors_event_t* data, int count); ./mediatek/proprietary/hardware/sensor/GlanceGesture.h:45: sensors_event_t mPendingEvent; ./mediatek/proprietary/hardware/sensor/GlanceGesture.h:50: virtual int readEvents(sensors_event_t* data, int count); ./mediatek/proprietary/hardware/sensor/Proximity.cpp:64: mPendingEvent.version = sizeof(sensors_event_t); ./mediatek/proprietary/hardware/sensor/Proximity.cpp:253:int ProximitySensor::readEvents(sensors_event_t* data, int count)
0x0000000a00000068中的0xa是sensors_event_t结构中的sensor的值，这个看起来是sensor ID，这些ID是在device下定义的。
@device/mediatek/common/kernel-headers/linux/hwmsensor.h #define SENSOR_TYPE_LINEAR_ACCELERATION 10 #define SENSOR_TYPE_ROTATION_VECTOR 11 ... #define SENSOR_TYPE_SIGNIFICANT_MOTION 17 #define SENSOR_TYPE_STEP_DETECTOR 18 ... #define ID_BASE 0 ... #define ID_ACCELEROMETER (ID_BASE+SENSOR_TYPE_ACCELEROMETER-1) #define ID_LINEAR_ACCELERATION (ID_BASE+SENSOR_TYPE_LINEAR_ACCELERATION-1) #define ID_ROTATION_VECTOR (ID_BASE+SENSOR_TYPE_ROTATION_VECTOR-1) #define ID_GRAVITY (ID_BASE+SENSOR_TYPE_GRAVITY-1) #define ID_GYROSCOPE (ID_BASE+SENSOR_TYPE_GYROSCOPE-1)
这个ID是ID_ROTATION_VECTOR，这样可以进一步缩小范围
vendor$ cgrep ID_ROTATION_VECTOR
./mediatek/proprietary/hardware/sensor/nusensors.cpp:145: case ID_ROTATION_VECTOR:
./mediatek/proprietary/hardware/sensor/hwmsen_chip_info.c:766: .handle = ID_ROTATION_VECTOR+ID_OFFSET,
./mediatek/proprietary/hardware/sensor/BstSensor.cpp:207: case ID_ROTATION_VECTOR:
./mediatek/proprietary/hardware/sensor/BstSensor.cpp:265: case ID_ROTATION_VECTOR:
./mediatek/proprietary/hardware/sensor/BstSensor.cpp:352: case ID_ROTATION_VECTOR:
./mediatek/proprietary/hardware/sensor/BstSensor.cpp:411: case ID_ROTATION_VECTOR:
这里由于对sensors_event_t不熟悉，所以后面对ID的判断其实是很虚的，所以没有继续往下跟。决定直接上coredump。
由于此时已经找到了稳定的复现路径，所以抓取coredump也容易了，一共抓了5组coredump。
对每一份做了内存分析，发现都是大量的数据被覆盖，至少是几百K，
而且看起来出问题的时候还再写（出问题时结束位置——104字节对齐不明显），起始位置也没有堆chunk的head。
其中有一个对应的tombstone很可疑：
pid: 15788, tid: 15810, name: SensorService >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa00000080
backtrace:
#00 pc 00000000000096a0 /system/lib64/hw/sensors.mt6795.so (sensors_poll_context_t::pollEvents(sensors_event_t*, int)+400)
#01 pc 000000000000a474 /system/lib64/libsensorservice.so
#02 pc 0000000000010eb0 /system/lib64/libsensorservice.so
#03 pc 00000000000179c0 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+188)
#04 pc 000000000009277c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+96)
#05 pc 0000000000017224 /system/lib64/libutils.so
#06 pc 000000000001cbb0 /system/lib64/libc.so (__pthread_start(void*)+52)
#07 pc 0000000000019044 /system/lib64/libc.so (__start_thread+16)
这个backtrace #00的sensors.mt6795.so库就是sensor hardware的代码，而当前还是确实也在操作sensors_event_t结构的指针。
加载该tombstone对应的coredump：
(gdb) core core-SensorService-15788 (gdb) bt #0 0x0000007f6a79d6a0 in sensors_poll_context_t::pollEvents (this=0x5575a43b20, data=http://www.mamicode.com/0x5575a60c78, count=-653) at vendor/mediatek/proprietary/hardware/sensor/nusensors.cpp:470 #1 0x0000007f6a7e6478 in android::SensorDevice::poll (this=this@entry=0x5575a863a0, buffer=0x5575a49b30, count=count@entry=256) at frameworks/native/services/sensorservice/SensorDevice.cpp:123 #2 0x0000007f6a7eceb4 in android::SensorService::threadLoop (this=0x5575a43880) at frameworks/native/services/sensorservice/SensorService.cpp:409 #3 0x0000007f7f99c9c4 in android::Thread::_threadLoop (user=user@entry=0x5575a438a0) at system/core/libutils/Threads.cpp:776 #4 0x0000007f7fc9f780 in android::AndroidRuntime::javaThreadShell (args=<optimized out>) at frameworks/base/core/jni/AndroidRuntime.cpp:1258 #5 0x0000007f7f99c228 in thread_data_t::trampoline (t=<optimized out>) at system/core/libutils/Threads.cpp:101 #6 0x0000007f7fe56bb4 in __pthread_start (arg=0x7f7ba4e000, arg@entry=<error reading variable: value has been optimized out>) at bionic/libc/bionic/pthread_create.cpp:141 #7 0x0000007f7fe53048 in __start_thread (fn=<optimized out>, arg=<optimized out>) at bionic/libc/bionic/clone.cpp:41 #8 0x0000000000000000 in ?? ()
backtrace中，#0里的count是-653，而#1的count值是256。
也 就是说android::SensorDevice::poll()调用sensors_poll_context_t::pollEvents() 时，count还是256，但在 sensors_poll_context_t::pollEvents()做处理时变成了负数。
一般count不应该是负数，所以很可能 sensors_poll_context_t::pollEvents()的逻辑有问题，
加上这个函数又是上面列出的重点怀疑的文件nusensors.cpp中定义的。所以这里出问题的可能性很大。
@vendor/mediatek/proprietary/hardware/sensor/nusensors.cpp int sensors_poll_context_t::pollEvents(sensors_event_t* data, int count) { int nbEvents = 0; int n = 0; //ALOGE("pollEvents count =%d",count ); do { // see if we have some leftover from the last poll() for (int i=0 ; count && i<numSensorDrivers ; i++) { SensorBase* const sensor(mSensors[i]); if ((mPollFds[i].revents & POLLIN) || (sensor->hasPendingEvents())) { int nb = sensor->readEvents(data, count); ... //if(nb < 0||nb > count) //ALOGE("pollEvents count error nb:%d, count:%d, nbEvents:%d", nb, count, nbEvents);//for sensor NE debug count -= nb; nbEvents += nb; data += nb; //if(nb < 0||nb > count) // ALOGE("pollEvents count error nb:%d, count:%d, nbEvents:%d", nb, count, nbEvents);//for sensor NE debug } } ... } while (n && count); return nbEvents; }
关键是下面这一句：
nb = sensor->readEvents(data, count);
这句话的意思应该是往data指向的地址中填写event，count是要读取的event个数，nb返回的是已读取的event个数。
这种方法类似于read()函数的，while循环能保证读取到count个数的event。
而这时如果nb返回异常呢？当然，从gdb中可以确定nb确实异常了。
然而我们sensors_poll_context_t::pollEvents()中没有对这个异常值做任何的保护，所以就会出问题。
当count为负数时sensors_poll_context_t::pollEvents()的while循环很难会退出，所以越界覆盖的buffer也应该很长。
当覆盖的内存刚好被别的线程访问，那个线程就会crash，而此时应该有线程在执行sensors_poll_context_t::pollEvents()函数。
再看看其他core：
(gdb) core core-InputReader-32381
(gdb) bt
#0 art::Mutex::ExclusiveLock (this=this@entry=0xa00000068, self=self@entry=0x5597cc1f80) at art/runtime/base/mutex.cc:311
#1 0x0000007fafb410e0 in MutexLock (mu=..., self=0x5597cc1f80, this=<synthetic pointer>) at art/runtime/base/mutex.h:423
#2 art::gc::allocator::RosAlloc::AllocFromRun (this=0x5597c1efe0, self=self@entry=0x5597cc1f80, size=size@entry=20, bytes_allocated=0x75f8c7f8, bytes_allocated@entry=0x7f9c42f088)
at art/runtime/gc/allocator/rosalloc.cc:672
#3 0x0000007fafd57650 in Alloc<true> (bytes_allocated=0x7f9c42f088, size=20, self=0x5597cc1f80, this=<optimized out>) at art/runtime/gc/allocator/rosalloc-inl.h:33
#4 AllocCommon<true> (usable_size=0x7f9c42f080, bytes_allocated=0x7f9c42f078, num_bytes=20, self=0x5597cc1f80, this=<optimized out>) at art/runtime/gc/space/rosalloc_space-inl.h:57
#5 AllocNonvirtual (usable_size=0x7f9c42f080, bytes_allocated=0x7f9c42f078, num_bytes=20, self=0x5597cc1f80, this=<optimized out>) at art/runtime/gc/space/rosalloc_space.h:71
#6 TryToAllocate<false, false> (usable_size=0x7f9c42f080, bytes_allocated=0x7f9c42f078, alloc_size=20, allocator_type=art::gc::kAllocatorTypeRosAlloc, self=0x5597cc1f80, this=<optimized out>)
at art/runtime/gc/heap-inl.h:208
#7 AllocObjectWithAllocator<false, false, art::VoidFunctor> (pre_fence_visitor=..., allocator=art::gc::kAllocatorTypeRosAlloc, byte_count=20, klass=0x6fce4650, self=0x5597cc1f80, this=<optimized out>)
at art/runtime/gc/heap-inl.h:80
#8 Alloc<false, false> (allocator_type=art::gc::kAllocatorTypeRosAlloc, self=0x5597cc1f80, this=<optimized out>) at art/runtime/mirror/class-inl.h:561
#9 AllocObjectFromCodeInitialized<false> (method=<optimized out>, allocator_type=art::gc::kAllocatorTypeRosAlloc, self=0x5597cc1f80, klass=<optimized out>)
at art/runtime/entrypoints/entrypoint_utils-inl.h:170
上面这个是被覆盖的线程，可以用info thread查看同一时刻其他线程的状态：
(gdb) info thread
Id Target Id Frame
100 LWP 1525 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
99 LWP 32456 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
98 LWP 1586 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
97 LWP 581 nanosleep () at bionic/libc/arch-arm64/syscalls/nanosleep.S:7
96 LWP 2156 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
95 LWP 32465 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
94 LWP 32464 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
...
21 LWP 32483 __accept4 () at bionic/libc/arch-arm64/syscalls/__accept4.S:7
20 LWP 32444 recvmsg () at bionic/libc/arch-arm64/syscalls/recvmsg.S:7
19 LWP 32403 sensors_poll_context_t::pollEvents (this=0x5597c20eb0, data=http://www.mamicode.com/0x5597c21ca0, count=-402) at vendor/mediatek/proprietary/hardware/sensor/nusensors.cpp:470
18 LWP 32413 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
...
5 LWP 1106 __ppoll () at bionic/libc/arch-arm64/syscalls/__ppoll.S:7
4 LWP 923 __ioctl () at bionic/libc/arch-arm64/syscalls/__ioctl.S:7
3 LWP 32441 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
2 LWP 32467 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
* 1 LWP 32442 art::Mutex::ExclusiveLock (this=this@entry=0xa00000068, self=self@entry=0x5597cc1f80) at art/runtime/base/mutex.cc:311
上面19号线程可以看出，它正在执行sensors_poll_context_t::pollEvents()，同时count值也是负数。
再看一个：
(gdb) core core-SensorEventAckR-15999 (gdb) bt #0 android::Looper::pollInner (this=0x558c9e0bd0, timeoutMillis=<optimized out>) at system/core/libutils/Looper.cpp:286 #1 0x0000007f9e1cc884 in android::Looper::pollOnce (this=0x558c9e0bd0, timeoutMillis=timeoutMillis@entry=-1, outFd=outFd@entry=0x0, outEvents=outEvents@entry=0x0, outData=http://www.mamicode.com/outData@entry=0x0)>
(gdb) info thread
Id Target Id Frame
101 LWP 17316 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
100 LWP 17588 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
99 LWP 16075 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
98 LWP 16080 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
97 LWP 20823 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
96 LWP 16082 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
95 LWP 19034 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
...
11 LWP 16036 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
10 LWP 16392 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
9 LWP 16021 0x0000007f88fc96a0 in sensors_poll_context_t::pollEvents (this=0x558c5cbe40, data=http://www.mamicode.com/0x558ca1fcc0, count=-3472) at vendor/mediatek/proprietary/hardware/sensor/nusensors.cpp:470
8 LWP 16107 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
7 LWP 16031 __epoll_pwait () at bionic/libc/arch-arm64/syscalls/__epoll_pwait.S:9
6 LWP 16034 0x0000007f9e738104 in ?? ()
5 LWP 16104 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
4 LWP 16061 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
3 LWP 16060 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
2 LWP 16085 syscall () at bionic/libc/arch-arm64/bionic/syscall.S:41
* 1 LWP 16024 android::Looper::pollInner (this=0x558c9e0bd0, timeoutMillis=<optimized out>) at system/core/libutils/Looper.cpp:286
加入debug code：
int sensors_poll_context_t::pollEvents(sensors_event_t* data, int count) { int nbEvents = 0; int n = 0; //ALOGE("pollEvents count =%d",count );do { // see if we have some leftover from the last poll() for (int i=0 ; count && i<numSensorDrivers ; i++) { SensorBase* const sensor(mSensors[i]); if ((mPollFds[i].revents & POLLIN) || (sensor->hasPendingEvents())) { int nb = sensor->readEvents(data, count); if(nb < 0 || nb > count) { nb += *(int*)0; //运行到这里时，触发native crash } ...
重新抓取coredump：
(gdb) bt #0 sensors_poll_context_t::pollEvents (this=0x55827f7610, data=http://www.mamicode.com/0x5582c7b170, count=256) at vendor/mediatek/proprietary/hardware/sensor/nusensors.cpp:474 #1 0x0000007f92352478 in android::SensorDevice::poll (this=this@entry=0x5582be0ee0, buffer=0x5582c7b170, count=count@entry=256) at frameworks/native/services/sensorservice/SensorDevice.cpp:123 #2 0x0000007f92358eb4 in android::SensorService::threadLoop (this=0x55827f7370) at frameworks/native/services/sensorservice/SensorService.cpp:409 #3 0x0000007fa75089c4 in android::Thread::_threadLoop (user=user@entry=0x55827f7390) at system/core/libutils/Threads.cpp:776 #4 0x0000007fa780b780 in android::AndroidRuntime::javaThreadShell (args=<optimized out>) at frameworks/base/core/jni/AndroidRuntime.cpp:1258 #5 0x0000007fa7508228 in thread_data_t::trampoline (t=<optimized out>) at system/core/libutils/Threads.cpp:101 #6 0x0000007fa79c2bb4 in __pthread_start (arg=0x7fa35b9000, arg@entry=<error reading variable: value has been optimized out>) at bionic/libc/bionic/pthread_create.cpp:141 #7 0x0000007fa79bf048 in __start_thread (fn=<optimized out>, arg=<optimized out>) at bionic/libc/bionic/clone.cpp:41 #8 0x0000000000000000 in ?? ()
查看变量：
(gdb) info locals nb = 2235 sensor = <optimized out> i = 5 nbEvents = 0 n = 1
nb值(2235)确实比count值(256)大！
再看看是哪个sensor：
(gdb) p mSensors
$2 = {0x5582c2db80, 0x55827f80c0, 0x5582c22dd0, 0x5582c23ec0, 0x5582c27fa0, 0x5582be02b0, 0x5582c268b0, 0x5582c251c0, 0x5582c296a0, 0x5582c2ada0, 0x5582c2c490, 0x5582c30560, 0x5582c33340, 0x5582c31c50,
0x5582c70a60, 0x5582c71b40, 0x5582c73230, 0x5582c74920, 0x5582c76010, 0x5582c77700, 0x5582c78df0}
i值是5，那sensor就是0x5582be02b0了。
(gdb) p *(SensorBase*) 0x5582be02b0
$3 = {_vptr.SensorBase = 0x7f923317c0 <vtable for BstSensor+16>, dev_name = 0x0, data_name = 0x7f9231c698 "/data/misc/sensor/fifo_dat", dev_fd = -1, data_fd = 40}
找到虚函数表指针为0x7f923317c0，看下虚函数表中的内容：
(gdb) x /16gx 0x7f923317c0 0x7f923317c0 <_ZTV9BstSensor+16>: 0x0000007f92317e58 0x0000007f92317e94 0x7f923317d0 <_ZTV9BstSensor+32>: 0x0000007f923181a4 0x0000007f92309ab8 0x7f923317e0 <_ZTV9BstSensor+48>: 0x0000007f92309ab0 0x0000007f92317eb8 0x7f923317f0 <_ZTV9BstSensor+64>: 0x0000007f92318020 0x0000007f92317e18 0x7f92331800 <_ZTV9BstSensor+80>: 0x0000007f92317e20 0x0000000000000001 0x7f92331810: 0x000000000000283c 0x0000000000000001 0x7f92331820: 0x0000000000002844 0x0000000000000001 0x7f92331830: 0x0000000000002851 0x0000000000000001
可以知道，这个sensor类是BstSensor。又挨个试得知对应的readEvents为0x0000007f923181a4。
(gdb) disassemble 0x0000007f923181a4 Dump of assembler code for function BstSensor::readEvents(sensors_event_t*, int): 0x0000007f923181a4 <+0>: stp x29, x30, [sp,#-176]! 0x0000007f923181a8 <+4>: cmp w2, wzr 0x0000007f923181ac <+8>: mov x29, sp 0x0000007f923181b0 <+12>: stp x19, x20, [sp,#16]
看源码：
@vendor/mediatek/proprietary/hardware/sensor/BstSensor.cpp int BstSensor::readEvents(sensors_event_t *pdata, int count) { ...while (rslt < count) { err = read(data_fd, &sensor_data, sizeof(sensor_data)); ... delta_mod= (float)(time-bst_last_ts[index])/(float)(bst_delay[index]); /* if delta_mode > x.5, loopcount = x+1 */ loopcount = (int)(delta_mod+0.5); ...for(int i=1; i<=loopcount; i++) { pdata_cur->version = sizeof(*pdata_cur); pdata_cur->sensor = sensor; pdata_cur->timestamp = time - (loopcount-i)*bst_delay[index]; switch (sensor) { ...case ID_ROTATION_VECTOR: pdata_cur->data[0] = sensor_data.data.data[0]; pdata_cur->data[1] = sensor_data.data.data[1]; pdata_cur->data[2] = sensor_data.data.data[2]; pdata_cur->data[3] = sensor_data.data.data[3]; pdata_cur->data[4] = sensor_data.data.data[4]; pdata_cur->type = SENSOR_TYPE_ROTATION_VECTOR; break; default: ALOGE("<BST> " "Invalid data pkt"); return rslt; } rslt++; pdata_cur++; } bst_last_ts[index] = time; } return rslt; }
关键是这个loopcount大于传入buffer的大小count的时候，返回值有可能大于count。这里可能需要做保护！
【解决方案】
diff --git a/proprietary/hardware/sensor/BstSensor.cpp b/proprietary/hardware/sensor/BstSensor.cpp index cc21b37..ea84bea 100755 --- a/proprietary/hardware/sensor/BstSensor.cpp +++ b/proprietary/hardware/sensor/BstSensor.cpp @@ -320,7 +320,9 @@ int BstSensor::readEvents(sensors_event_t *pdata, int count) sensors_event_t *pdata_cur; int loopcount; float delta_mod; + int count_bk; + count_bk = count; if (count > 1) { count = 1; } @@ -388,7 +390,10 @@ int BstSensor::readEvents(sensors_event_t *pdata, int count) bst_last_ts[index] = time; loopcount = 1; } - + if(loopcount >=count_bk) + { + loopcount = count_bk; + } for(int i=1; i<=loopcount; i++) {
MTK Sensor越界导致的系统重启问题分析报告
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。