定位到程序崩溃的地方，TOMBSTONE

每次遇到TOMBSTONE，在堆栈中都会存了一些相关的信息。

如：

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 6166617b
 eax 00000028  ebx 41307340  ecx 4137c500  edx 096b8744
 esi 09cbf0f0  edi 61666153
 xcs 00000073  xds 0000007b  xes 0000007b  xfs 00000000 xss 0000007b
 eip 41222a3f  ebp 4fe3fcc8  esp 4fe3fbe0  flags 00010202
    #00  eip: 0008da3f  /system/lib/libdvm.so (_Z15dvmDumpThreadExPK17DebugOutputTargetP6Threadb+0x4f)
    #01  eip: 0008dec4  /system/lib/libdvm.so (_Z13dvmDumpThreadP6Threadb+0x54)
    #02  eip: 000a6e8b  /system/lib/libdvm.so (dvmHandleStackOverflow+0x18b)
    #03  eip: 000a704c  /system/lib/libdvm.so (_Z15dvmPushJNIFrameP6ThreadPK6Method+0xfc)
    #04  eip: 0008fcdd  /system/lib/libdvm.so (_Z22dvmAttachCurrentThreadPK16JavaVMAttachArgsb+0x22d)
    #05  eip: 00076239  /system/lib/libdvm.so (_ZL12attachThreadP7_JavaVMPP7_JNIEnvPvb+0xd9)
    #06  eip: 001cd5ed  /system/lib/libwebcore.so (_ZN3WTFL25runThreadWithRegistrationEPv+0x3d)
    #07  eip: 0000eca2  /system/lib/libc.so (__thread_entry+0x42)
stack: 
    #00  4fe3fbe0  61666153  
    #00  4fe3fbe4  00000000  
    #00  4fe3fbe8  00000000  
    #00  4fe3fbec  00000000  

大爷的，以前没学过什么C++， JAVA,只知道这里是发生了段错误，在c++中，_Z15dvmDumpThreadExPK17DebugOutputTargetP6Threadb，这些符号表不同于c,它的意思不
但跟传进的参数类型有关，而且前面的那些z15什么的我现在也不知道，自己在找规律，方正这些都是死的，从下到上，结果发现后面的数字 0x**,竟然与接下来调用的函数有关，
大家来看看：
我先吧libdvm.so 进行了反汇编：objdump libdvm.so -d >1
                           vim 1
0008fab0 <_Z22dvmAttachCurrentThreadPK16JavaVMAttachArgsb>:
   8fab0:       55                      push   %ebp
   8fab1:       89 e5                   mov    %esp,%ebp
   8fab3:       57                      push   %edi
   8fab4:       56                      push   %esi
   8fab5:       53                      push   %ebx
   8fab6:       e8 c6 d4 f9 ff          call   2cf81 <__x86.get_pc_thunk.bx>
   8fabb:       81 c3 85 28 0e 00       add    $0xe2885,%ebx
   8fac1:       8d 64 24 94             lea    -0x6c(%esp),%esp
   8fac5:       8b bb b4 fd ff ff       mov    -0x24c(%ebx),%edi
   8facb:       0f b6 45 0c             movzbl 0xc(%ebp),%eax
   8facf:       c7 44 24 04 60 04 00    movl   $0x460,0x4(%esp)
   8fad6:       00
   8fad7:       88 45 d3                mov    %al,-0x2d(%ebp)
   8fada:       c7 04 24 01 00 00 00    movl   $0x1,(%esp)
   8fae1:       8b 57 14                mov    0x14(%edi),%edx
....................
 8fccb:       8b 87 c4 02 00 00       mov    0x2c4(%edi),%eax
   8fcd1:       89 34 24                mov    %esi,(%esp)
   8fcd4:       89 44 24 04             mov    %eax,0x4(%esp)
   8fcd8:       e8 73 72 01 00          call   a6f50 <_Z15dvmPushJNIFrameP6ThreadPK6Method>


如在这个函数 dvmAttachCurrentThread里面调用子其 dvmPushJNIFrame，相差就是在汇编的call这里，用8fcd8-8fab0+5=0x22d,呵呵，屡次都是这个样子啊。
这样的话，就可以很快的找到崩溃的地方了。
还有一种方法，这种还是高手的经验告诉我的。就是直接找到库libdvm.so,然后对其进行反汇编，直接去找到0008da3f这个地址就行了。这点我有点想法，不知道是对的不：
因为libdvm.so是个动态的库，在makefile中会有个链接这个些程序的位置，然后才生成这些动态库的，虽然在运行时它地址只是相对的，但是这也就能查到我们能需要的地
放了。
好了就看看这个地址的汇编到底是个啥
8da23:       c7 44 24 04 00 00 00    movl   $0x0,0x4(%esp)
   8da2a:       00
   8da2b:       89 3c 24                mov    %edi,(%esp)
   8da2e:       e8 9d 37 00 00          call   911d0 <dvmAddTrackedAlloc>
   8da33:       8b 8b b4 fd ff ff       mov    -0x24c(%ebx),%ecx
   8da39:       8b 81 30 02 00 00       mov    0x230(%ecx),%eax
   8da3f:       8b 04 07                mov    (%edi,%eax,1),%eax
   8da42:       89 8d 48 ff ff ff       mov    %ecx,-0xb8(%ebp)
   8da48:       89 04 24                mov    %eax,(%esp)
   8da4b:       e8 10 30 00 00          call   90a60 <_Z23dvmCreateCstrFromStringPK12StringObject>
呵呵，汇编的话，我也只是个半调子水，不管了，硬着头皮看看吧。在别的微博中了解了一下这些调用的规则，和这些寄存器的大概作用，大概可以定位是edi这个地址错了，
这个时候就要一步一步往上面走，看看到底是那个变量的地址错了，为什么会发生越界。
不过最后我虽然找到是那个变量发生了越界，但是要我看看一步一步跟着看这个为什么会错误，我觉得我之所以是个菜鸟的原因就是想偷点懒了，暂时不想继续弄下去了。如果
继续，倒时候再告诉大家啊。