gdb debug

 

 

 

使用disas 查看crash的点的汇编代码

“=>”符号指示的为crash对应的汇编code。

 

 

使用infor查看寄存器情况（也可以在Log中的tombstone文件中查看）

 

④Issue 分析

1. dbdc8:      91116044        add    x4, x2, #0x458
2. dbdcc:      f9422c41        ldr    x1, [x2,#1112]
3. dbdd0:      f9400482       ldr      x2, [x4,#8] ç Crash here

 

tombstone：

1. pid: 1052, tid: 2072, name: Binder_D >>> system_server <<<
2. signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), faultaddr 0x8

tombstone中最后提示的fault addr 0x8是因为汇编crash的最后一行，是x4+8=x2,但此时x4为0，所以x2为0x8,访问错误，汇编code 再向上2行，

1. add     x4,x2, #0x458

复制代码

x4=x2+#0x458, 此时x2=7f850db000 ,所以x4=0x7f850db458,但x4实际值却是0，所以这条issue应该是因为register corruption on x4 导致的SIGSEGV。

通常分析至该步骤后，可以请SSD Stability team或是bsp team帮忙看。

 --------------------------------------------------------------------------------------------------------------------------------------

Issue 2

查看crash call stack的frame0和frame1对应的源代码，可以通过http://androidxref.htc.com:8080/source/ 在线查询源码，先选择右边的project,（此处可选择L50_Mainline_CRC_MAR）然后左侧输入“File Path”: art/runtime/instrumentation.cc, 点击“Search”，通过查看frame0和frame1的代码发现由DexPcMovedEvent调用DexPcMovedEventImpl时同是属于Instrumentation类，所以frame1和frame2中的this 值应该相等，但实际却不相等。

283  // Inform listeners that the dex pc has moved (onlysupported by the interpreter).
284  void DexPcMovedEvent(Thread* thread,mirror:bject* this_object,
285                      mirror::ArtMethod* method, uint32_t dex_pc) const
286     SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {
287    if (UNLIKELY(HasDexPcListeners())) {
288      DexPcMovedEventImpl(thread,this_object, method, dex_pc);
289    }
290  }

深入分析：

直接disas,查看frame0对应的汇编：

 

先输入f 1(移动到frame1对应的function)，再输入disas,找到frame1 crash点对应的汇编

 

Tombstone信息:

pid: 1119, tid: 1143, name: Binder_2  >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR),fault addr 0x9fa00009
x0  000000009fa00001  x1   0000000000000000  x2  00000055812cb900  x3   0000000000000000
x4  0000000071ecbe99  x5   0000000000000000  x6  00000055806a1ad8  x7   0000000000000000
x8   0000000000000000  x9  7391994266d9758c  x10  0000000000000000  x11 0000000000430000
x12 0000000000550000  x13  0000000000430000  x14 0000000000000000  x15  0000007f7da18000
x16 0000007f7da1a470  x17  000000000000002f  x18 0000007f7d966000  x19  00000000000003e2
x20 0000007f7d632e70  x21  00000055812cb900  x22 00000000707aa2d0  x23  0000000013d45d20
x24 0000000013d45cc0  x25  000000005f535052  x26 00000000704db090  x27  0000000071ecbe99
x28 0000000012e66000  x29  0000007f65333870  x30 0000007f7d632e78
sp  0000007f65333870  pc   0000007f7d76ae88  pstate 0000000060000000

fault addr 0x9fa00009，从寄存器信息看确实是x0+8, 但是结合上面的汇编code,

mov x0, x20 -> copy x0 to x20

所以x0的值应该是和x20值相同，即x20: 0000007f7d632e70  也就是上面分析的frame1中的this值，所以这条issue 也是CPU register corruption导致的

 

 

~/soft/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/objdump  -S -D libart.so