首先看一些这些线上app crash 信息
*** -[__NSArrayM objectAtIndexedSubscript:]: index 1 beyond bounds for empty array(null)
((
0 CoreFoundation 0x000000018608637c + 148
1 libobjc.A.dylib 0x00000001852cc528 objc_exception_throw + 56
2 CoreFoundation 0x000000018601ee9c _CFArgv + 0
3 CoreFoundation 0x000000018600bfb8 + 188
4 appname 0x1000b145c appname + 726108
5 UIKit 0x000000018f8ac394 + 68
6 UIKit 0x000000018f633d04 + 1856
7 UIKit 0x000000018f636120 + 108
8 UIKit 0x000000018f63606c + 152
9 UIKit 0x000000018f635a88 + 1512
10 appname 0x1004a0b20 appname + 4852512
11 appname 0x1000b11f0 appname + 725488
12 appname 0x100168378 appname + 1475448
13 UIKit 0x000000018fb2d04c + 100
14 UIKit 0x000000018f8a2ac4 + 664
15 UIKit 0x000000018f8a3028 + 80
16 UIKit 0x000000018f8818ac + 2336
17 UIKit 0x000000018f63833c + 140
18 UIKit 0x000000018f564f00 + 1276
19 QuartzCore 0x000000018a0c9998 + 184
20 QuartzCore 0x000000018a0cdb20 + 332
21 QuartzCore 0x000000018a03a36c + 336
22 QuartzCore 0x000000018a061b90 + 540
23 QuartzCore 0x000000018a0629d0 + 92
24 CoreFoundation 0x000000018602dedc + 32
25 CoreFoundation 0x000000018602b894 + 412
26 CoreFoundation 0x000000018602be50 + 1292
27 CoreFoundation 0x0000000185f4be58 CFRunLoopRunSpecific + 436
28 GraphicsServices 0x0000000187df8f84 GSEventRunModal + 100
29 UIKit 0x000000018f5cb67c UIApplicationMain + 236
30 appname 0x1003fbcfc appname + 4177148
31 libdyld.dylib 0x0000000185a6856c + 4
)
dSYM UUID: F35F2E31-ABCA-3AD4-9015-E598A78A904E
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: HBStockWarning
Base Address: 0x00000001041dc000
SIGSEGV和SIGBUS 一般都是因为访问已经被释放的内存或者调用不存在的方法导致的
这些具体的crash log 什么都看不出来，都是一些内存地址，帧调用栈等，所以需要进一步的解析，看下文：
发现有一句
4 appname 0x1003fbcfc appname + 4177148
它指出了应用名称，崩溃时的调用方法的地址，文件的地址以及方法所在的行的位置,接下来就要符号化（Symbolication）这句,用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配
打开终端
cd /Users/hbzq/Desktop/appname\ 2017-12-25\ 16.47.xcarchive/dSYMs
//取出本地保存的dSYM文件看 是否和崩溃的文件匹配
dwarfdump --uuid appname.app.dSYM
UUID: CB2A59CC-EFAB-32E4-A2A0-703CA181B260 (armv7)
UUID: F35F2E31-ABCA-3AD4-9015-E598A78A904E (arm64)
OK,crash log中的dSYM UUID与本地的dYSM文件是相匹配的。好接下来就查一下0x1003fbcfc这个地址是什么
dwarfdump --arch=arm64 --lookup 0x1003fbcfc /Users/hbzq/Desktop/appname\ 2017-12-25\ 16.47.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/HBStockWarning
特别注意：--arch=arm64 这个arm64是根据 友盟的 CPU Type 的值来写的有的可能是armv7
得到结果
Looking up address: 0x00000001000b145c in .debug_info... found!
0x000e2fe8: Compile Unit: length = 0x00000ca5 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000e3c91)
0x000e2ff3: TAG_compile_unit [111] *
AT_producer( "Apple LLVM version 9.0.0 (clang-900.0.38)" )
AT_language( DW_LANG_ObjC )
AT_name( "/Users/Jimmy/appname/HBStockWarning/HBStockModule/StockQuote/StructuredFund/StructureHome/Views/HBArbitrageTableViewCell.m" )
AT_stmt_list( 0x0004ef9f )
AT_comp_dir( "/Users/Jimmy/appname" )
AT_APPLE_optimized( 0x01 )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x00000001000b0a04 )
AT_high_pc( 0x00000001000b1c5c )
0x000e363a: TAG_subprogram [153] *
AT_low_pc( 0x00000001000b13a0 )
AT_high_pc( 0x00000001000b14cc )
AT_frame_base( reg29 )
AT_object_pointer( {0x000e3662} )
AT_name( "-[HBArbitrageTableViewCell tableView:numberOfRowsInSection:]" )
AT_decl_file( "/Users/Jimmy/HBStockWarning/appname/HBStockModule/StockQuote/StructuredFund/StructureHome/Views/HBArbitrageTableViewCell.m" )
AT_decl_line( 118 )
AT_prototyped( 0x01 )
AT_type( {0x0000000000015cd8} ( NSInteger ) )
AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/Jimmy/appname/appname/HBStockModule/StockQuote/StructuredFund/StructureHome/Views'
Line table file: 'HBArbitrageTableViewCell.m' line 124, column 28 with start address 0x00000001000b1454
>Looking up address: 0x00000001000b145c in .debug_frame... not found.
接着我们发现 AT_name、 AT_decl_file、 Line table dir : 这基本就能定位到问题了 这里发现在 HBArbitrageTableViewCell 的 124行有问题
当然我们还会发现另外一种情况 。 这就很尴尬
Looking up address: 0x00000001003fbcfc in .debug_info... found!
0x0039d187: Compile Unit: length = 0x0000012c version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0039d2b7)
0x0039d192: TAG_compile_unit [111] *
AT_producer( "Apple LLVM version 9.0.0 (clang-900.0.38)" )
AT_language( DW_LANG_ObjC )
AT_name( "/Users/Jimmy/HBStockWarning/HBStockWarning/main.m" )
AT_stmt_list( 0x001a73ce )
AT_comp_dir( "/Users/Jimmy/appname" )
AT_APPLE_optimized( 0x01 )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x00000001003fbca4 )
AT_high_pc( 0x00000001003fbd24 )
0x0039d25c: TAG_subprogram [205] *
AT_low_pc( 0x00000001003fbca4 )
AT_high_pc( 0x00000001003fbd24 )
AT_frame_base( reg29 )
AT_name( "main" )
AT_decl_file( "/Users/Jimmy/appname/appname/main.m" )
AT_decl_line( 13 )
AT_prototyped( 0x01 )
AT_type( {0x0039d29e} ( int ) )
AT_external( 0x01 )
AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/Jimmy/appname/appname'
Line table file: 'main.m' line 15, column 16 with start address 0x00000001003fbce8
首先你要明白，很多这种情况是已经释放的对象再调用其方法就会产生EXC_BAD_ACCESS这样的报错
介绍个用xcode定位崩溃主函数的方法吧（实际就是开启僵尸检测）
Xcode自带Zombie检测的开关
image.png
第一：点这里，选择edit scheme
image
这个时候，你把刚才崩溃的程序再来一遍，令人发指的打印出现了
image
**控制台输出**
**2016-11-10 16:59:17.272 XXXXX[14999:433907] *** -[XXXXXXXX respondsToSelector:]:**
**message sent to deallocated instance 0x7fa37d8a0c00**
这太强了有没有，瞬间定位到了哪个对象成为了僵尸对象，而你还在对他进行访问，死也死不瞑目，然后你就炸了！