• 解析IOS崩溃日志(crash Log) 2015-01-30 18:30:37
    http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/ http://blog.csdn.net/smking/article/details/9342899 最近在解析umeng错误分析日志上有了重大突破!   很显然,我们的应用...

    http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/

    http://blog.csdn.net/smking/article/details/9342899


    最近在解析umeng错误分析日志上有了重大突破!
    
      很显然,我们的应用免不了crash,各种各样的crash,不过大部分在提交至appstore前经过严格的“消毒”后,所剩无几了。but(这个词..)漏网之鱼总是有的嘛(貌似很多..囧)。好吧,看下文:
    
      首先看一些这些线上app crash 信息:
    
    * Application received signal SIGSEGV
    * Application received signal SIGBUS
    * -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
    * -[JKArray objectAtIndex:]: index (0) beyond bounds (0)
    SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的,余下两个就是数组越界的问题了 这些你都知道的,然后来看看具体的log信息:
    
    Application received signal SIGSEGV
    
    Application received signal SIGSEGV
    (null)
    (
    0   CoreFoundation                      0x32f1c3ff  + 186
    1   libobjc.A.dylib                     0x3ac17963 objc_exception_throw + 30
    2   CoreFoundation                      0x32f1c307  + 106
    3   appname                            0x14e1e1 appname + 1364449
    4   libsystem_c.dylib                   0x3b08bd33 _sigtramp + 34
    5   appname                            0x97525 appname + 615717
    6   CoreFoundation                      0x32e6d349 _CFXNotificationPost + 1420
    7   Foundation                          0x337879cd  + 168
    8   Foundation                          0x337876c1  + 136
    9   appname                            0x96f2f appname + 614191
    10  Foundation                          0x33858915  + 16
    11  Foundation                          0x33798769  + 200
    12  Foundation                          0x33798685  + 60
    13  CFNetwork                           0x32bf964f  + 26
    14  CFNetwork                           0x32bf8d33  + 54
    15  CFNetwork                           0x32c21013  + 18
    16  CoreFoundation                      0x32e62acd CFArrayApplyFunction + 176
    17  CFNetwork                           0x32c21473  + 74
    18  CFNetwork                           0x32b85461  + 188
    19  CoreFoundation                      0x32ef18f7  + 14
    20  CoreFoundation                      0x32ef115d  + 212
    21  CoreFoundation                      0x32eeff2f  + 646
    22  CoreFoundation                      0x32e6323d CFRunLoopRunSpecific + 356
    23  CoreFoundation                      0x32e630c9 CFRunLoopRunInMode + 104
    24  GraphicsServices                    0x36a4233b GSEventRunModal + 74
    25  UIKit                               0x34d7f2b9 UIApplicationMain + 1120
    26  appname                            0xf3df appname + 58335
    27  appname                            0x3578 appname + 9592
    )
    
    dSYM UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3
    CPU Type: armv7s
    Slide Address: 0x00001000
    Binary Image: appname
    Base Address: 0x000f7000
    –[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
    
    *** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
    (null)
    (
    0   CoreFoundation                      0x330dc3ff  + 186
    1   libobjc.A.dylib                     0x3add7963 objc_exception_throw + 30
    2   CoreFoundation                      0x33027ef9  + 164
    3   appname                            0xcbcaf appname + 830639
    4   appname                            0x40bc1 appname + 261057
    5   appname                            0x3d297 appname + 246423
    6   UIKit                               0x34f36569  + 408
    7   UIKit                               0x34f1b391  + 1316
    8   UIKit                               0x34f32827  + 206
    9   UIKit                               0x34eee8c7  + 258
    10  QuartzCore                          0x34c9a513  + 214
    11  QuartzCore                          0x34c9a0b5  + 460
    12  QuartzCore                          0x34c9afd9  + 16
    13  QuartzCore                          0x34c9a9c3  + 238
    14  QuartzCore                          0x34c9a7d5  + 316
    15  QuartzCore                          0x34c9a639  + 60
    16  CoreFoundation                      0x330b1941  + 20
    17  CoreFoundation                      0x330afc39  + 276
    18  CoreFoundation                      0x330aff93  + 746
    19  CoreFoundation                      0x3302323d CFRunLoopRunSpecific + 356
    20  CoreFoundation                      0x330230c9 CFRunLoopRunInMode + 104
    21  GraphicsServices                    0x36c0233b GSEventRunModal + 74
    22  UIKit                               0x34f3f2b9 UIApplicationMain + 1120
    23  appname                            0xf3df appname + 58335
    24  appname                            0x3578 appname + 9592
    )
    
    dSYM UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3
    CPU Type: armv7s
    Slide Address: 0x00001000
    Binary Image: appname
    Base Address: 0x000c3000
    好了,相信你也看出来了,这些具体的crash log 什么都看不出来,都是一些内存地址,帧调用栈等,所以需要进一步的解析,看下文:
    
    看一下上面的crash log,找到一句
    
    5   appname                            0x97525 appname + 615717
    它指出了应用名称,崩溃时的调用方法的地址,文件的地址以及方法所在的行的位置(具体请看这篇文章),接下来就要符号化(Symbolication)这句,用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配
    
    打开终端:
    
    cd /Users/username/Library/Developer/Xcode/Archives/2013-08-30/app 8-30-13 6.19 PM.xcarchive/dSYMs
    dwarfdump --uuid appname.app.dSYM
    UUID: 9F0AEFA6-4349-30AF-8420-BCEE739DA0B4 (armv7) appname.app.dSYM/Contents/Resources/DWARF/appname
    UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3 (armv7s) appname.app.dSYM/Contents/Resources/DWARF/appname
    OK,crash log中的dSYM UUID与本地的dYSM文件是相匹配的。好接下来就查一下0x97525这个地址是什么,
    
    dwarfdump --arch=armv7 --lookup 0x97525  /Users/username/Library/Developer/Xcode/Archives/2013-08-30/appname\ 8-30-13\ 6.19\ PM.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname
    得到的结果:
    
    ----------------------------------------------------------------------
    File: /Users/username/Library/Developer/Xcode/  Archives/2013-08-30/appname 8-30-13 6.19    PM.xcarchive/dSYMs/appname.app.dSYM/Contents/   Resources/DWARF/appname (armv7)
    ----------------------------------------------------------------------
    Looking up address: 0x0000000000097525 in .debug_info... found!
    
    0x00359c67: Compile Unit: length = 0x000066f1  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x0036035c)
    
    0x00359c72: TAG_compile_unit [1] *
             AT_producer( "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "xxx/EGOImageView.m" )
             AT_low_pc( 0x0009710c )
             AT_stmt_list( 0x000655c1 )
             AT_comp_dir( "xxx" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
    
    0x00359e57:     TAG_subprogram [10] *
                 AT_name( "-[EGOImageView imageLoaderDidFailToLoad:]" )
                 AT_decl_file( "xxx/EGOImageView.m" )
                 AT_decl_line( 96 )
                 AT_prototyped( 0x01 )
                 AT_APPLE_isa( 0x01 )
                 AT_low_pc( 0x00097490 )
                 AT_high_pc( 0x00097572 )
                 AT_frame_base( r7 )
                 AT_object_pointer( {0x00359e6e} )
    Line table dir : 'xxx'
    Line table file: 'EGOImageView.m' line 99, column 2 with start address 0x00000000000974fe
    
    Looking up address: 0x0000000000097525 in .debug_frame... found!
    
    0x0000c620: FDE
        length: 0x0000000c
        CIE_pointer: 0x00000000
        start_addr: 0x00097490 -[EGOImageView imageLoaderDidFailToLoad:]
    range_size: 0x000000e2 (end_addr = 0x00097572)
    Instructions: 0x00097490: CFA=4294967295+4294967295
    看一下结果:发现有AT_name、Line table dir :、Line table file:,aha!找到了出错的地方(出错的这个文件是网上别人写的,有bug,现已不再使用)。
    
    注意:如果发现warning: unsupported file type:错误,这个问题是因为有文件或者目录的名称中包含空格,比如:2013-08-30/appname 8-30-13 6.19 ,所以,需要转义一下:2013-08-30/appname\ 8-30-13\ 6.19\ PM.xcarchive


    展开全文
  • (转载)ios崩溃日志详解 2016-12-07 09:56:37
    crash的产生来源于两种问题:违反iOS策略被干掉,以及自身的代码bug。 1.IOS策略 1.1 低内存闪退 前面提到大多数crash日志都包含着执行线程的栈调用信息,但是低内存闪退日志除外,这里就先看看低内存闪退...
  • 获取 iOS crash log 2014-05-23 23:08:10
    ios开发过程中,经常会遇到应用在开发过程中或者自己测试时不会有问题。而在安装到别人设备上,或者上传应用商店被别人下载的时候,总是被抱怨程序不定期的crash,真的很令人懊恼!   获取 iOS crash log ...
  • iOS日志及崩溃抓取 2019-09-26 17:57:50
    在日常开发及测试中很容易出现比较难以复现的崩溃,这种bug往往让我们无处下手,日志抓取帮我们很好的解决了这个问题。 DDLog的使用 首先可以在pch文件中定义log等级 static const DDLogLevel ddLogLevel = ...
  • 1.打印log可以打印有颜色的log,前提是安装第三方插件。压缩包附带颜色的第三方插件。如果想打印颜色,必须先安装。类似第三方注释,直接运行就好。然后退出xcode,有LoadBundle提示证明你安装成功。 2.打印崩溃日志...
  • iOS 记录crash日志 2016-07-07 16:07:52
    项目开发过程中经常会遇到crash的问题,现在有比较好的统计工具,但有时我们只是需要了解造成crash的原因,使用友盟等显得有些浪费。现在可以自己动手写记录crash。ZWCrashRecordTool添加了两个方法: ...
  • 解析iOS崩溃日志 2016-04-07 12:45:37
    iOS APP崩溃后,会生成一个崩溃日志xxx.crash。但是crash日志里都是一些地址信息,可读性很低。
  • iOS 崩溃Crash解析 2017-03-07 15:43:05
    iOS崩溃是让iOS开发人员比较头痛的事情,app崩溃了,说明代码写的有问题,这时如何快速定位到崩溃的地方很重要。调试阶段是比较容易找到出问题的地方的,但是已经上线的app并分析崩溃报告就比较麻烦了。 之前我...
  • ios Log 真机测试 log
  • [我用了http://www.tuicool.com/articles/VzEBBn,里面的方法,还有这个里面的方法http://www.cocoachina.com/industry/20140514/8418.html到底哪种方法是对的啊 崩溃代码到底怎么锁定啊!!!图片说明]...
  • iOS崩溃日志分析 2015-11-20 17:36:34
    iOS崩溃日志分析 iOS崩溃日志分析 崩溃日志的产生 iOS中运行App过程中如果发生程序崩溃,会生成一个崩溃日志文件。这个文件会保存的特定系统目录下,扩展名是crash。你可以通过系统设置中的“通用-关于本机-诊断...
  • 一次Unity-ios崩溃追踪 2017-03-13 23:01:07
    现象:在IOS上的真机包,在某特定的场景中突然卡住,任何地方无法响应点击事件,模型也不在渲染,没有崩溃 查找问题:在bugly中看到崩溃日志,定位到是资源问题,但是无法定位到具体某一个资源,使用Xcode连调定位...
  • iOS崩溃堆栈还原 2014-04-27 17:54:30
    我们以前定位crash的流程如下: 到iFunshion.app.dsym(app对应的符号文件)目录下,执行命令 atos -o 'iFunshion.app.dSYM/Contents/...到ios4.3以后,直接用“十六进制的崩溃内存地址”就不能定位到正确的程序代
  • iOS crash log 获取及分析 2017-05-23 09:44:05
    ios开发过程中,经常会遇到应用在开发过程中或者自己测试时不会有问题。而在安装到别人设备上,或者上传应用商店被别人下载的时候,总是被抱怨程序不定期的crash,真的很令人懊恼! 获取 iOS crash log ...
  • iOS:crash崩溃日志分析 2018-04-12 15:22:50
    一、前言:作为一个合格的iOS开发者,除了具有规范强悍的编码能力外,还应该具有过硬的查错纠错能力。在项目运行时,程序崩溃是不可避免的,遇到这个问题,有时会出现一大堆的crash日志,艹,貌似看不懂呀。其实没有...
  • 深入理解iOS Crash Log 2018-07-06 21:11:36
    Crash Log Crash Log的主要来源有两种: Apple提供的,可以从用户设备中直接拷贝,或者从iTunes Connect(XCode)下载 三方或者自研Framework统计,三方服务包括Fabric,Bugly等。 这篇文章讲到的Crash Log是...
  • 对于那些做后端开发的工程师来说,看LOG解Bug应该是理所当然的事,但我接触到的移动应用开发的工程师里面,很多人并没有这个意识,查Bug时总是一遍一遍的试图重现,试图调试,特别是对一些不太容易重现的Bug经常...
  • iOS 获取崩溃日志 2016-12-13 13:48:09
    有几种方法可以从设备上获取崩溃日志。设备与电脑上的iTunes Store同步后,会将崩溃日志保存在电脑上。根据电脑操作系统的不同,崩溃日志将保存在以下位置: Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/...
  • iOS 解析crashlog日志 2019-11-15 14:21:04
    AppStore上架被拒如何解析crash文件: 最近上架被拒,提示如下; 1 Performance: App Completeness Guideline 2.1 - ...Your app crashed on iPad running iOS 13.2.2 on WiFi when we: Launch > Tapped T...
1 2 3 4 5 ... 20
收藏数 7,263
精华内容 2,905
热门标签