分析线上crash调用栈

app上线之后,一定会有线上的bug,可以通过符号化还原出来具体的奔溃栈,从而分析出来具体的问题所在
今天我也遇到了,因为是第一天改项目,然后不是特别懂,最后同事帮助我解决了这个问题.

总结:一定要去好公司,才会有一批的高手,教你很多东西


奔溃栈

要注意,就是Thread 0 Crashed:就是主线程的意思

奔溃栈,一定要找到对应的系统才行哈,否则反汇编的结果有可能不对,crash的是8.0系统,我们测试还原的是用的8.1.4. 反汇编是一样的,但是我们看了一下使用ios10.x系统,就不可以

这个就是具体的调用栈信息,然后我们就可以找了。

思路:

1.看看+200这个位置到底是是啥玩意

图片.png

根据崩溃栈信息来看,问题直接定位在了[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:]函数,所以我们直接在这里设置断点.

设置符号断点

注意,当我们设置断点到了这个函数,应该去找到奔溃点---+ 196,因为+200的时候已经执行完函数,此时的$x0寄存器已经发生了变化,看不到具体的参数了.

-[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:] + 200
ios8.x的xcode断点图

然后定位到了+196(+200)的上一条指令位置,objc_sendmsg,奔溃位置!!!

通过打印出来x0,x21,x8,来确定出具体的东西,x21表示的是self,可以通过汇编代码查出来,也可以打印出来,x8表示的是ivar_offset,一个偏移值,也就是说,是一个window的变量,要去打印出来x8存的东西

register read x8

//获取的是一个比较小的数字,0xc8,后来经过鉴定,是delegate

//超哥教我看汇编

    0x18b2b1f24 <+168>: adrp   x8, 54619
    0x18b2b1f28 <+172>: ldrsw  x8, [x8, #0xf7c]
->  0x18b2b1f2c <+176>: ldr    x0, [x21, x8] //将x21(window)加上 x8的值,然后放回x0位置,  window->delegate,此时的x8内部是一个比较小的数字
    0x18b2b1f30 <+180>: adrp   x8, 54571  //更新了x8数据
    0x18b2b1f34 <+184>: nop    
    0x18b2b1f38 <+188>: ldr    x1, [x8, #0x980]
    0x18b2b1f3c <+192>: mov    x2, x22
    0x18b2b1f40 <+196>: bl     0x18b7bb708   //直接crash  (ios8中,其他的并没有crash,模拟的时候,也没有crash),打印出来的结果是SAKModalViewController
    0x18b2b1f44 <+200>: mov    x24, x0
    
(lldb) register read x8
      x8 = 0x00000000000000c8
(lldb) 

//打印寄存器的某个属性
(lldb) po [(id)$x21 delegate]
<SAKModalViewController: 0x12f76e3a0>

因为这个在我们这里并没有浮现出来,但是不是说不存在,我们的思路就是看看为甚会奔溃,然后解决

结论:

这里就可以断定,一定是SAKModalViewController这个对象已经释放了,导致了在+196这个位置crash

-[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:] + 200
这个位置表示的是在这个函数里面crash的,但并不是因为调用了他crash的,
真正的元凶是SAKModalViewController没有了,此时打印寄存器x1,
现实的的这个方法 "M",因为这个问题,所以调用了“M”方法,导致了整个项目的crash。

结论

SAKModalViewController释放的时候,我们没有设置window.delegate = nil,所以导致了野指针,项目发生了crash,这也就是为什么,在项目中我们经常看到别人的代码经常写到

xxx.delegate = nil

之所以我们这crash只有在ios8中发生,在其他的系统,和我们模拟的过程中没有发生crash,是因为ios8中的tableview.scrollview.collectionview.delegate都是用assign修饰的,当这个对象释放的时候,都会有 crash的可能,而之后,都是用weak修饰的,如果对象释放了,我们会将所有的weak指针指向nil,从而不会发生crash

解决方法

SAKModalViewController控制器销毁的时候,将UIWindowdelegate设置为nil即可.

2.再看一步

根据上边的结论,我们就知道为甚了,就是看看接下来的crash的真实位置objc_msgSend + 16,看看这个+16位置到底做了什么,依旧使用符号断电

libobjc.A.dylib`objc_msgSend:
->  0x196f6fbc0 <+0>:   cmp    x0, #0x0                  ; =0x0 
    0x196f6fbc4 <+4>:   b.le   0x196f6fc30               ; <+112>
    0x196f6fbc8 <+8>:   ldr    x13, [x0]
    0x196f6fbcc <+12>:  and    x9, x13, #0x1fffffff8
    0x196f6fbd0 <+16>:  ldp    x10, x11, [x9, #0x10]   //找到这个位置
    0x196f6fbd4 <+20>:  and    w12, w1, w11
    0x196f6fbd8 <+24>:  add    x12, x10, x12, lsl #4

从奔溃的地方往上分析

/***********************/
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
//这个是0x0000000000000010就是这个0x10,这个是呼应,切记
Exception Codes: KERN_INVALID_TASK at 0x0000000000000010
Crashed Thread:  0
/***********************/

//一.x10 = x9 + 0x10,但是在这里crash了.这个位置和奔溃栈呼应了
ldp    x10, x11, [x9, #0x10]   //找到这个位置

//二.x9和x13执行了与操作
0x196f6fbcc <+12>:  and    x9, x13, #0x1fffffff8

//三.从x0存的位置中取出来一个内容,给x13寄存器,应该是[x0] = nil,导致了问题.
0x196f6fbc8 <+8>:   ldr    x13, [x0]

推荐阅读更多精彩内容