用GDB推导DVM的Java栈

... } (gdb) p * (Thread *) 0x7b88a3a8 $4 = { ... threadId = 26, ... status = THREAD_NATIVE, systemTid = 25905, interpStackStart = 0x77ead000 <Address 0x77ead000 out of bounds>, threadObj = 0x42dacd70, jniEnv = 0x7a0cff28, prev = 0x414d0558, next = 0x7a095de0, ... }

...

用info thread命令可以看到，出问题的线程是23405线程，也就是主线程。

(gdb) info thread
  Id   Target Id         Frame
  54   LWP 23412         recvmsg () at bionic/libc/arch-arm/syscalls/recvmsg.S:9
  53   LWP 23451         __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:39
  ...
  5    LWP 23460         __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:39
  4    LWP 23418         __ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:9
  3    LWP 25905         __ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:9
  2    LWP 23417         __ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:9
* 1    LWP 23405         tgkill () at bionic/libc/arch-arm/bionic/tgkill.S:46

接下来就开始推导主线程的调用栈：

(gdb) p *(Thread*)0x414d0558
$3 = {
  interpSave = {
    pc = 0x6e601544,
    curFrame = 0x6d556e20,
    ...
  },
  threadId = 1,
  ...
  status = THREAD_NATIVE,
  systemTid = 23405,
  interpStackStart = 0x6d557000 "",
  threadObj = 0x416b2ca8,
  jniEnv = 0x414cefa8,
  ...
  prev = 0x0,
  next = 0x7b88a3a8,
  ...
}

从interpSave的curFrame可以推导最顶层的StackSaveArea，由于:

#define SAVEAREA_FROM_FP(_fp)   ((StackSaveArea*)(_fp) -1)

所以最顶层的StackSaveArea为：

(gdb) p *(StackSaveArea*)(0x6d556e20-sizeof(StackSaveArea))
$5 = {
  prevFrame = 0x6d556e40,
  savedPc = 0x7015e73c,
  method = 0x6d7d6068,
  ...
}

取Method：

(gdb) p *(Method*) 0x6d7d6068
$6 = {
  clazz = 0x4187f7b8,
  accessFlags = 258,
  methodIndex = 0,
  registersSize = 3,
  outsSize = 0,
  insSize = 3,
  name = 0x701b6c59 <Address 0x701b6c59 out of bounds>,
  ...
}

取Method对应的ClassObject:

(gdb) p *(ClassObject*) 0x4187f7b8
$7 = {
  ...
  descriptor = 0x7019bc6d <Address 0x7019bc6d out of bounds>,
  ...
}

对照map表，发现是这个descriptor的地址是webviewchromium的dex文件:

7012e000-701ef000 r--p 00000000 b3:1b 40987      /data/dalvik-cache/system@framework@webviewchromium.jar@classes.dex

descriptor的地址减去dex的起始地址，就得到类名称字符串在dex中的偏移地址:

(gdb) p /x 0x7019bc6d-0x7012e000
$8 = 0x6dc6d

从手机中pull出来这个dex文件后，用hexdump查看：

$ hexdump -C -n64 -s0x6dc6d system@framework@webviewchromium.jar@classes.dex
0006dc6d  4c 63 6f 6d 2f 61 6e 64  72 6f 69 64 2f 6f 72 67  |Lcom/android/org|
0006dc7d  2f 63 68 72 6f 6d 69 75  6d 2f 62 61 73 65 2f 53  |/chromium/base/S|
0006dc8d  79 73 74 65 6d 4d 65 73  73 61 67 65 48 61 6e 64  |ystemMessageHand|
0006dc9d  6c 65 72 3b 00 2b 4c 63  6f 6d 2f 61 6e 64 72 6f  |ler;.+Lcom/andro|

可知，这个类的名称是com/android/org/chromium/base/SystemMessageHandler

Method里有name成员，表示函数名，它的偏移地址为：

(gdb) p *(Method*) 0x6d7d6068
$6 = {
  clazz = 0x4187f7b8,
  accessFlags = 258,
  methodIndex = 0,
  registersSize = 3,
  outsSize = 0,
  insSize = 3,
  name = 0x701b6c59 <Address 0x701b6c59 out of bounds>,
  ...
}

(gdb) p /x 0x701b6c59-0x7012e000
$9 = 0x88c59

同样用hexdump就能得到这个函数名:

$ hexdump -C -n32 -s0x88c59 system@framework@webviewchromium.jar@classes.dex
00088c59  6e 61 74 69 76 65 44 6f  52 75 6e 4c 6f 6f 70 4f  |nativeDoRunLoopO|
00088c69  6e 63 65 00 17 6e 61 74  69 76 65 44 6f 63 75 6d  |nce..nativeDocum|

最顶层的函数名为nativeDoRunLoopOnce()。

再看看次顶层,次顶层的frame保存在顶层StackSaveArea的prevFrame成员里：

(gdb) p *(StackSaveArea*)(0x6d556e20-sizeof(StackSaveArea))
$5 = {
  prevFrame = 0x6d556e40,
  ...
}

(gdb) p *(StackSaveArea*)(0x6d556e20-sizeof(StackSaveArea))
$5 = {
  prevFrame = 0x6d556e40,
  savedPc = 0x7015e73c,
  method = 0x6d7d6068,
  ...
}

(gdb) p *(StackSaveArea*)(0x6d556e40-sizeof(StackSaveArea))
$12 = {
  prevFrame = 0x6d556e64,
  savedPc = 0x6edd27f0,
  method = 0x6d7d6150,
  ...
}

(gdb) p *(Method*) 0x6d7d6150
$13 = {
  clazz = 0x4187f7b8,
  accessFlags = 1,
  methodIndex = 16,
  registersSize = 4,
  outsSize = 3,
  insSize = 2,
  name = 0x701b091d <Address 0x701b091d out of bounds>,
  ...
}

clazz和顶层的一样是com/android/org/chromium/base/SystemMessageHandler。

method name的偏移地址：

(gdb) p /x 0x701b091d-0x7012e000
$17 = 0x8291d

函数名为handleMessage():

$ hexdump -C -n32 -s0x8291d system@framework@webviewchromium.jar@classes.dex
0008291d  68 61 6e 64 6c 65 4d 65  73 73 61 67 65 00 0e 68  |handleMessage..h|
0008292d  61 6e 64 6c 65 4e 61 76  69 67 61 74 65 00 10 68  |andleNavigate..h|

再推导下一个栈:

(gdb) p *(StackSaveArea*)(0x6d556e64-sizeof(StackSaveArea))
$34 = {
  prevFrame = 0x6d556e84,
  savedPc = 0x6efdd434,
  method = 0x6d5f75a0,
  ...
}

(gdb) p *(Method*)0x6d5f75a0
$35 = {
  clazz = 0x416e0ad8,
  accessFlags = 1,
  methodIndex = 11,
  registersSize = 3,
  outsSize = 2,
  insSize = 2,
  name = 0x6f28d6c6 <Address 0x6f28d6c6 out of bounds>,
  ...
}

(gdb) p *(ClassObject*)0x416e0ad8
$36 = {
  ...
  descriptor =  <Address 0x6f1e621b out of bounds>,
  ...
}

6ec32000-6edaa000 r--p 00000000 b3:1b 40972      /data/dalvik-cache/system@framework@framework.jar@classes.dex
...
6f127000-6f586000 r--p 004f5000 b3:1b 40972      /data/dalvik-cache/system@framework@framework.jar@classes.dex


(gdb) p /x 0x6f1e621b-0x6ec32000
$40 = 0x5b421b

$ hexdump -C -n32 -s0x5b421b system@framework@framework.jar@classes.dex
005b421b  4c 61 6e 64 72 6f 69 64  2f 6f 73 2f 48 61 6e 64  |Landroid/os/Hand|
005b422b  6c 65 72 3b 00 1a 4c 61  6e 64 72 6f 69 64 2f 6f  |ler;..Landroid/o|

(gdb) p /x 0x6f28d6c6-0x6ec32000
$41 = 0x65b6c6

$ hexdump -C -n32 -s0x65b6c6 system@framework@framework.jar@classes.dex
0065b6c6  64 69 73 70 61 74 63 68  4d 65 73 73 61 67 65 00  |dispatchMessage.|
0065b6d6  0d 64 69 73 70 61 74 63  68 4d 6f 76 65 64 00 11  |.dispatchMoved..|

得到的调用栈大概就是:

com.android.org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce
com.android.org.chromium.base.SystemMessageHandler.handleMessage
android.os.Handler.dispatchMessage
...

 

用GDB推导DVM的Java栈

标签：手机   shared   函数   jnienv   access   chm   list   odi   from