【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 cm