iOS开发如何通过UMeng的错误分析解决crash问题

最新推荐文章于 2025-12-31 20:24:24 发布

转载最新推荐文章于 2025-12-31 20:24:24 发布 · 4k 阅读

文章标签：

#ios开发 #bug #友盟

Swift 同时被 2 个专栏收录

37 篇文章

订阅专栏

From Android to Swift

22 篇文章

订阅专栏

本文详细介绍如何利用友盟统计的错误分析功能定位并解决iOS App的Crash问题，包括如何解析SIGSEGV错误日志，查找对应xcarchive文件及dSYMUUID，使用dwarfdump工具定位崩溃的具体代码位置。

友盟统计有一个很适用的功能是错误分析，通过它我们可以看到App的一些crash错误，对于定位问题有帮助，那么如何根据这些错误日志解决bug呢？

今天在友盟的错误分析里面找到了一个这样的错误：

Application received signal SIGSEGV
(null)
(
    0   CoreFoundation                      0x2ef6dfeb  + 154
    1   libobjc.A.dylib                     0x3971cccf objc_exception_throw + 38
    2   CoreFoundation                      0x2ef6df15  + 0
    3   appname                          0xcc979 appname + 821625
    4   libsystem_platform.dylib            0x39d43f8b _sigtramp + 34
    5   UIKit                               0x31842261  + 44
    6   UIKit                               0x31842261  + 44
    7   UIKit                               0x31842261  + 44
    8   UIKit                               0x318ab1d9  + 256
    9   UIKit                               0x3182d97f  + 142
    10  UIKit                               0x318aaefd  + 128
    11  UIKit                               0x31808115  + 312
    12  UIKit                               0x31808407  + 106
    13  UIKit                               0x31884c37  + 46
    14  Foundation                          0x2f94d163 __NSFireDelayedPerform + 414
    15  CoreFoundation                      0x2ef391b7  + 14
    16  CoreFoundation                      0x2ef38dcf  + 782
    17  CoreFoundation                      0x2ef3716b  + 1210
    18  CoreFoundation                      0x2eea1f0f CFRunLoopRunSpecific + 522
    19  CoreFoundation                      0x2eea1cf3 CFRunLoopRunInMode + 106
    20  GraphicsServices                    0x33da6663 GSEventRunModal + 138
    21  UIKit                               0x317ed16d UIApplicationMain + 1136
    22  veryWallen                          0x85613 veryWallen + 529939
    23  libdyld.dylib                       0x39c29ab7  + 2
)
 
dSYM UUID: 76634C55-B73F-303D-BA7C-511D5B84D45A
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: veryWallen
Base Address: 0x0008b000

Application received signal SIGSEGV
(null)<br><span style="background-color: #ff6600;">SIGSEGV</span>和<span style="background-color: #ff6600;">SIGBUS</span>一般是因为访问已被释放的内存或者调用不存在的方法导致的，那么上面所说的崩溃信息基本就能定性为内存被释放啦？问题是在哪里崩溃的呢，完全不知道啊，所以只能往里找了。<br>使用showinfinder进入

/Users/username（电脑名）/Library/Developer/Xcode/Archives/这个文件夹，你会看到你打包时生成的xcarchive文件，当然你得用Archives来打包。
然后来查找正确的包吧，也就是崩溃程序的这个包的dSYM UUID必须和上面崩溃信息的一样。

打开终端，输入cd 然后拖进

xcarchive
文件吧，记得加上/dSYMs然后回车,这样你就进入了/dSYMs的目录了，再输入

dwarfdump --uuid appname.app.dSYM

命令，可别脑子坏掉的也输appname就成，然后你就能看到

armv7 和 armv7s的 两个UUID了，对比下就能知道是否是这个包了，不是就继续试直到找到位置


当你找到是哪个包了在来看下一步。。。

看看这句

3   appname                          0xcc979 appname + 821625

这就是崩溃时调用的地方，在终端继续输入

dwarfdump --arch=armv7 --lookup 0xcc979 对应的包的路径/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname

就会得出结果，如果你前面没有敲错，那么你应该能看到不一样的Log信息，不是么，

----------------------------------------------------------------------
 File: /Users/username/Library/Developer/Xcode/Archives/2014-10-16/veryWallen 14-10-16 上午11.51.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname (armv7)
----------------------------------------------------------------------
Looking up address: 0x0000000000097525 in .debug_info... found!

0x00223f5a: Compile Unit: length = 0x000021d9  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x00226137)

0x00223f65: TAG_compile_unit [1] *
             AT_producer( "Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking/AFHTTPSessionManager.m" )
             AT_stmt_list( 0x0006eca0 )
             AT_comp_dir( "/Users/paobao/Documents/veryWallen/Pods" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x00096888 )

0x002253ff:     TAG_subprogram [10] *
                 AT_name( "-[AFHTTPSessionManager POST:parameters:constructingBodyWithBlock:success:failure:]" )
                 AT_decl_file( "/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking/AFHTTPSessionManager.m" )
                 AT_decl_line( 179 )
                 AT_prototyped( 0x01 )
                 AT_type( {0x00224de4} ( NSURLSessionDataTask* ) )
                 AT_APPLE_isa( 0x01 )
                 AT_accessibility( DW_ACCESS_public )
                 AT_low_pc( 0x00097454 )
                 AT_high_pc( 0x000976ec )
                 AT_frame_base( r7 )
                 AT_object_pointer( {0x0022541b} )
Line table dir : '/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking'
Line table file: 'AFHTTPSessionManager.m' line 185, column 0 with start address 0x00000000000974a4

Looking up address: 0x0000000000097525 in .debug_frame... found!

0x0000c930: FDE
        length: 0x0000000c
   CIE_pointer: 0x00000000
    start_addr: 0x00097454 -[AFHTTPSessionManager POST:parameters:constructingBodyWithBlock:success:failure:]
    range_size: 0x00000298 (end_addr = 0x000976ec)
  Instructions: 0x00097454: CFA=4294967295+4294967295