dYSM分析崩溃日志

前言


相信很多朋友都使用了友盟统计这个SDK吧，能够统计出我们崩溃的日志，但是反馈的日志是无法确定到底是哪里发生崩溃的，那么我们如何去查呢？

dYSM是打包的时候生成的，位于/Users/<用户名>/Library/Developer/Xcode/Archives下，找到它就可以拿友盟统计上的错误日志来查找崩溃在程序的哪个类哪行代码了。不过，这不是绝对的，有的日志是查不到崩溃在何处的。

查找dYSM文件


在友盟统计上，错误日志这里会有应用的版本号，我们要根据这个版本号，找到我们对应的ipa包，然后找到dYSM文件。在错误日志的下位，有出错的版本号，出错的次数，出错的首次日期，最后一次出现的日期。

如下：

[huangyibiao@huangyibiaodeMacBook-Pro ~] $ cd /Users/huangyibiao/Library/Developer/Xcode/Archives/
[huangyibiao@huangyibiaodeMacBook-Pro ~/Library/Developer/Xcode/Archives] $ ls
2015-11-09  2015-11-27
[huangyibiao@huangyibiaodeMacBook-Pro ~/Library/Developer/Xcode/Archives] $ cd 2015-11-27/
[huangyibiao@huangyibiaodeMacBook-Pro ~/Library/Developer/Xcode/Archives/2015-11-27] $ ls
appName 15-11-27 上午11.02.xcarchive

这个是路径，改成自己电脑的用户名：/Users/huangyibiao/Library/Developer/Xcode/Archives/。最后，我们就是需要找到这个：appName 15-11-27 上午11.02.xcarchive

得到了这个东西，接下来就好办了！

学习分析日志


如下为友盟统计的一个错误日志：

*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[8]
(null)
(
    0   CoreFoundation                      0x000000018268654c  + 160
    1   libobjc.A.dylib                     0x000000019365c0e4 objc_exception_throw + 60
    2   CoreFoundation                      0x00000001825748e8  + 420
    3   CoreFoundation                      0x0000000182574718  + 72
    4   appName                             0x10062d8f8 appName + 6478072
    5   appName                             0x10062ab34 appName + 6466356
    6   appName                             0x100621344 appName + 6427460
    7   appName                             0x1001d2bd4 appName + 1911764
    8   UIKit                               0x0000000186ec8a14  + 96
    9   UIKit                               0x0000000186eb1d08  + 612
    10  UIKit                               0x0000000186ec83b0  + 592
    11  UIKit                               0x0000000186ec803c  + 700
    12  UIKit                               0x0000000186ec1590  + 684
    13  UIKit                               0x0000000186e94e60  + 264
    14  UIKit                               0x000000018713446c  + 15220
    15  UIKit                               0x0000000186e933d0  + 1716
    16  CoreFoundation                      0x000000018263ed34  + 24
    17  CoreFoundation                      0x000000018263dfd8  + 264
    18  CoreFoundation                      0x000000018263c088  + 712
    19  CoreFoundation                      0x00000001825691f4 CFRunLoopRunSpecific + 396
    20  GraphicsServices                    0x000000018b98b6fc GSEventRunModal + 168
    21  UIKit                               0x0000000186efa10c UIApplicationMain + 1488
    22  appName                             0x1003dcb3c appName + 4049724
    23  libdyld.dylib                       0x0000000193cdaa08  + 4
)

dSYM UUID: 67BB446B-A9F3-35A0-9A3D-9BCC3C55F9B9
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: appName
Base Address: 0x00000001000e4000

单看友盟日志，是看不出来到底在哪里崩溃的。不过日志中有了崩溃的地址，我们可以通过命令查出来到底是哪个类哪一行哪一列出现的崩溃。

我们点击上面的错误日志中第一个不是颜色比较特殊的一个地址，这里是0x10062d8f8，点击它就出弹出类似下面这样的：

看到这一行：dwarfdump --arch=arm64 --lookup 0x10062d8f8了吗，这就是用于查找地址0x10062d8f8错误信息的地址，然后就是指定我们对应的dYSM文件的路径：

加上dYSM路径后，形成这样的：

dwarfdump --arch=arm64 --lookup 0x1003dcb3c /Users/huangyibiao/Desktop/dSYMs/3.2.2\(10482\) appName\ 15-11-27\ 19.16.xcarchive/dSYMs/appName/Contents/Resources/DWARF/appName

注意：appName为自己应用的名称

然后一回车，我们得到类似如下的信息：

Looking up address: 0x00000001005234e4 in .debug_info... found!

0x0082c2d5: Compile Unit: length = 0x00002416  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0082e6ef)

0x0082c2e0: TAG_compile_unit [100] *
             AT_producer( "Apple LLVM version 7.0.0 (clang-700.0.72)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "../../HYBTestDemo/HYBTest/HYBTestController.m" )
             AT_stmt_list( 0x0028dd53 )
             AT_comp_dir( "/Users/huangyibiao/HYBDemo/HYBTest/" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x00000001005211b4 )
             AT_high_pc( 0x0000000100524114 )

0x0082dada:     TAG_subprogram [126] *
                 AT_low_pc( 0x00000001005231b8 )
                 AT_high_pc( 0x0000000100523570 )
                 AT_frame_base( reg29 )
                 AT_object_pointer( {0x0082dafa} )
                 AT_name( "-[HDFDemo post:parameters:success:failure:]" )
                 AT_decl_file( "/Users/huangyibiao/HYBTestDemo/HYBTestController.m" )
                 AT_decl_line( 330 )
                 AT_prototyped( 0x01 )
                 AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/huangyibiao/HYBTestDemo/HYBTest/HYBTestController.m'
Line table file: 'HYBTestController.m' line 369, column 1 with start address 0x00000001005234e4

上面的类名、方法名、项目名，笔者随便改了一下，只是不想让大家知道而已。不过这生成的就是类似这样子的。

然后，我们可以分析得到是在类HYBTestController中的第369行第1列崩溃的，就可以直接定位到错误的地方，然后分析出错的代码，fix掉就可以了。

通常无法定位错误的日志


像这种日志：

Application received signal SIGSEGV
(null)
(
    0   CoreFoundation                      0x0000000186e8a5b8  + 160
    1   libobjc.A.dylib                     0x00000001975e40e4 objc_exception_throw + 60
    2   CoreFoundation                      0x0000000186e8a4dc  + 0
    3   appName                             0x100869714 _ZN15CTXAppidConvert17IsConnectionAppIdEPKc + 1712168
    4   libsystem_platform.dylib            0x0000000197e0094c _sigtramp + 52
    5   CoreFoundation                      0x0000000186e30ae4  + 20
    6   CoreFoundation                      0x0000000186d6f220 _CFXNotificationPost + 2060
    7   Foundation                          0x0000000187c6ecc0  + 72
    8   UIKit                               0x000000018b8ca7e4  + 1132
    9   UIKit                               0x000000018b8d2cbc  + 92
    10  UIKit                               0x000000018b8d2c44  + 380
    11  UIKit                               0x000000018b8c6578  + 512
    12  FrontBoardServices                  0x000000018f0f962c  + 28
    13  CoreFoundation                      0x0000000186e42a28  + 20
    14  CoreFoundation                      0x0000000186e41b30  + 312
    15  CoreFoundation                      0x0000000186e40154  + 1756
    16  CoreFoundation                      0x0000000186d6d0a4 CFRunLoopRunSpecific + 396
    17  GraphicsServices                    0x000000018ff0f5a4 GSEventRunModal + 168
    18  UIKit                               0x000000018b6a23c0 UIApplicationMain + 1488
    19  appName                             0x1003dcb3c newPatient + 4049724
    20  libdyld.dylib                       0x0000000197c52a08  + 4
)

dSYM UUID: 67BB446B-A9F3-35A0-9A3D-9BCC3C55F9B9
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: appName
Base Address: 0x00000001000b0000

通常是分析不出来的，通过地址是无法查找出来的。像这种类型的bug目前还没有很好的解决方案。像这种错误，分析出来是这样的：

Looking up address: 0x0000000100869714 in .debug_info... not found.
Looking up address: 0x0000000100869714 in .debug_frame... not found.

查找地址失败，因此无法定位具体是哪里有问题，也就无法解决了。

写在最后


如果大家有对于上面这种查找不到地址的问题的解决方案，请在评论中回复一下，谢谢！！！

如果大家有对于上面这种查找不到地址的问题的解决方案，请在评论中回复一下，谢谢！！！

如果大家有对于上面这种查找不到地址的问题的解决方案，请在评论中回复一下，谢谢！！！

阅读原文

关注我


微信公众号：iOSDevShares
有问必答QQ群：324400294

时间： 2024-09-14 19:58:19

dYSM分析崩溃日志的相关文章

利用awstats分析nginx日志

今天打算分析下nginx日志,要分析nginx日志,我们可以通过shell脚本和第三方软件awstats进行分析,在此我们选择的是通过第三方软件awstats进行分析. 要使用awstats分析nginx日志,我们要安装awstats,而在安装awstats之前,我们需要先来介绍下awstats是什么? 一.awstats是什么 awstats是一个免费非常简洁而且强大有个性的基于Perl语言的WEB日志分析工具. 它可以统计网站的如下信息: 1):访问量.访问次数.页面浏览量.点击数.数据流量

网站日志里的秘密 分析网站日志有助于SEO

网站日志可以很好的记录访客和蜘蛛的访问情况,通过网站日志可以很好的了解网站的一些状况,这也是为什么现在很多SEO都会去分析网站日志的原因,但是分析网站日志的人不一定完全了解网站日志,下面我就浅谈一下网站日志里的秘密. 分析网站日志当然需要网站日志分析器,当然现在很多人使用免费的网站日志分析器,但是这些网站日志分析器分析出来的东西很有限,所以说很多网站信息也就被影藏了,下面我就以那种付费的网站日志分析器来阐述. 大家通过普通日志分析器一般都是看有没蜘蛛来过,什么蜘蛛,访问时间,访问哪些了页面.访问

SEO新手要学会查看和分析网站日志

作为SEO新手一定要学会查看和分析网站日志,因为从观看这些网站日志代码当中,可以分析出一个网站大体的状况. 网站日志中常见的代码: 网站日志记录了网民访问网站后返回的一些代码,其中常见的是200.304.404,返回代码200说明这个网站访问是正常的,返回代码404说明有一些错误的链接,已经访问不到链接的这个网页,这个情况大多数是站长删除了这个网页,如果返回是304说明这个网站已经很久没有更新了. 网站日志中常见的蜘蛛: 在网站日志中你可以看到一些搜索引擎的蜘蛛,常见的有:baiduspider

iOS 捕获程序崩溃日志

  我们常常会遇到iPhone手机或者iPad平板上运行APP崩溃的问题,有时候打开某个APP,却一下子"闪退"了.对于开发者来说,这个绝对是头疼的问题.那么如何获取到iOS设备崩溃日志呢?这个提供一些简单的方法,共开发者与用户沟通使用. iOS开发中遇到程序崩溃是很正常的事情,如何在程序崩溃时捕获到异常信息并通知开发者? 下面就介绍如何在iOS中实现: 1. 在程序启动时加上一个异常捕获监听,用来处理程序崩溃时的回调动作 代码如下: NSSetUncaughtExceptionHan

利用“崩溃轨迹”分析崩溃

原文出自[听云技术博客]:http://blog.tingyun.com/web/article/detail/777 "崩溃,严重伤害用户的情感,严重损害用户体验,罪恶行径简直令人发指,特请xx狮.xx猿火速缉拿案犯归案,刻不容缓,钦此." 虽然在"听云App"等类似优秀工具的帮助下,大多数的崩溃都能快速的.轻易的定位问题,如图: 上图所示,已经定位到某源文件的某行,再加上崩溃message,崩溃的原因就显而易见了. 但有些崩溃的原因就不是那么显而易见了,往往需要

一天，python搞个分析NGINX日志的脚本

准备给ZABBIX用的. 统计接口访问字次,平均响应时间,4XX,5XX次数 以后可以再改进.. #!/usr/bin/env python # coding: utf-8 ################################### # User:chengang # # Email:aguncn@163.com # # Date:2016-02-25 # ################################### import time import datetime

数据-python分析apache日志，大家看看错在哪

问题描述 python分析apache日志,大家看看错在哪 import os import json import http.client import codecs LogFile='/mnt/log/meiyiren.log' #日志 logMess='/tmp/acc.log' if os.path.isfile(logMess): os.system('cp /dev/null %s'% logMess) file=codecs.open(logMess,'w+',encoding='

在Linux上使用logwatch分析监控日志文件

1. 介绍 在维护Linux服务器时,经常需要查看系统中各种服务的日志,以检查服务器的运行状态. 如登陆历史.邮件.软件安装等日志.系统管理员一个个去检查会十分不方便:且大多时候,这会是一种被动的检查,即只有在发现系统运行异常时才会想到去查看日志以获取异常的信息.那么如何主动.集中的分析这些日志,并产生报告,定时发送给管理员就会显得十分重要. logwatch 是一款用 Perl 语言编写的开源日志解析分析器.它能对原始的日志文件进行解析并转换成结构化格式的文档,也能根据您的使用情况和需求来定制

代码混淆-android混淆代码后崩溃日志中不显示行号的问题

问题描述 android混淆代码后崩溃日志中不显示行号的问题 android混淆代码后崩溃日志中不显示行号,找崩溃的地方很不方便,如何解决,求大神指点,谢谢! 解决方案 问题已解决.原因是在混淆代码时默认会去掉class文件中的调试信息(源码的行号.源文件信息等),需要在混淆配置文件中申明保持这些信息: -renamesourcefileattribute SourceFile -keepattributes SourceFile,LineNumberTable 解决方案二: tks, 这个问题