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控制器销毁的时候，将UIWindow的delegate设置为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]