2016-11-30 18:04:50 Nine_Yao 阅读数 3143

1.下载umcrashtool工具

2.从友盟下载 .csv崩溃日志

3.将工具和日志放在同一目录下;

4.命令行输入

1)cd 步骤3中工具和文件的上层目录, 回车。例:cd /Users/xxx/Desktop/友盟错误分析

2) ./umcrashtool 步骤3日志的绝对路径,回车。例:./umcrashtool /Users/xxx/Desktop/友盟错误分析/sssss_错误分析_错误详情_154826.csv

5.等待解析

注:如果错误分析没有成功,请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。(对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下,因此建议保留该路径下的文件,以便后续用工具分析错误。)

2016-12-30 14:47:54 Felicity294250051 阅读数 3455

在发布阶段,如果用户的 App 发生了闪退,也就是崩溃了。我们应该如何得知,应该如何有效收集这些崩溃的日志信息。以助于我们的 App 更好的优化。


去 GitHub 下载一个框架:WZYCrash

https://github.com/CoderZYWang/WZYCrash


将 WZYCrash 集成到自己的项目中去。



共有三个类文件:

WZYUncaughtExceptionHandler(捕获崩溃信息),WZYCrashHandler(上传崩溃信息),WZYTools(获取手机型号)


集成完毕后,我们在 AppDelegate.m 中添加如下代码:

//
//  AppDelegate.m
//  WZYCrashDemo
//
//  Created by CoderZYWang on 2016/12/30.
//  Copyright © 2016年 wzy. All rights reserved.
//

#import "AppDelegate.h"

#import "WZYCrashHandler.h"
#import "WZYUncaughtExceptionHandler.h"

@interface AppDelegate ()

@end

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    
    // 捕获崩溃日志
    [WZYUncaughtExceptionHandler setDefaultHandler];
    // 上传崩溃日志到服务器
    [WZYCrashHandler uploadCrashLog];
    
    return YES;
}

@end


然后我们就可以用我们的代码进行测试,可以先自己写一个小错误然后测试一下是否集成成功。

//
//  ViewController.m
//  WZYCrashDemo
//
//  Created by CoderZYWang on 2016/12/30.
//  Copyright © 2016年 wzy. All rights reserved.
//

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    
    // 测试代码(运行demo时打开)
    // 数组越界错误
//    NSArray *arr = @[@"123"];
//    NSLog(@"%@", arr[3]);
    
    // 再次运行程序,在崩掉之前会有我们的打印信息(str 就是我们收集的错误信息)
    /*
     2016-12-30 14:14:26.883423 WZYCrashDemo[2693:1047098] str ---
     - IDENTIFIER_NUMBER:   6185368C-0054-49C6-8614-F91EA96A5FF3
     - OSVERSION:   10.0.2
     - PHONE_TYPE:   iPhone 6s
     - APP_VERSION:   1.0
     - name:
     NSRangeException
     - reason:
     *** -[__NSSingleObjectArrayI objectAtIndex:]: index 3 beyond bounds [0 .. 0]
     - callStackSymbols:
     0   CoreFoundation                      0x00000001844181d8 <redacted> + 148
     1   libobjc.A.dylib                     0x0000000182e5055c objc_exception_throw + 56
     2   CoreFoundation                      0x0000000184409428 <redacted> + 0
     3   WZYCrashDemo                        0x00000001000d3178 -[ViewController viewDidLoad] + 188
     4   UIKit                               0x000000018a2613dc <redacted> + 1056
     5   UIKit                               0x000000018a260fa4 <redacted> + 28
     6   UIKit                               0x000000018a267750 <redacted> + 76
     7   UIKit                               0x000000018a264bf0 <redacted> + 272
     8   UIKit                               0x000000018a2d7414 <redacted> + 48
     9   UIKit                               0x00000
     */
}

@end


还有疑问的话请参见 GitHub 上面的 Demo。


2016-08-18 22:44:38 skylin19840101 阅读数 827

iOS崩溃堆栈信息的符号化解析

 

   最近一段时间,在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。但在跟开发者沟通过程中,云捕小编发觉大家对iOS的应用符号表还不是很清楚。


    现在网上有很多关于解析崩溃堆栈信息的符号化的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天总结一下对ios崩溃符号化的使用和技巧:

一.场景

当我们收集iOS的崩溃信息时,获取到的崩溃堆栈一般是如下的形式,全是十六进制的内存地址形式:


这样的格式我们很难看出实际含义,无法定位问题代码,只有将它们转化为可读的形式才有意义:


如上所示,我们一眼就能看明白,这次崩溃发生在ViewController.m文件的68行,对应的方法是rangeException。那么这样的符号化又是如何实现的呢?

我们知道,开发者在使用Xcode开发调试App时,一旦遇到崩溃问题,开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线,用户的手机发生了崩溃,我们就只能通过分析系统记录的崩溃日志来定位问题,在这份崩溃日志文件中,会指出App出错的函数内存地址,关键的问题,崩溃日志中只有地址,类似 0x2312e92f这种,这看起来岂不是相当头疼,那怎么办呢?

幸好有dSYM文件的存在,它是帮助苦逼的码农有效定位bug问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上,在使用Xcode的Organizer查看崩溃日志时,就是根据本地存储的.dSYM文件进行了符号化的操作。

二.Xcode符号化工具

Xcode本身也提供了几个工具来帮助开发者执行函数地址符号化的操作

1、symbolicatecrash

symbolicatecrash是一个将堆栈地址符号化的脚本,输入参数是苹果官方格式的崩溃日志及本地的.dSYM文件,执行方式如下:

Symbolicatecrash + 崩溃日志 + APP对应的.dSYM文件 +> + 输出到的文件

但使用symbolicatecrash工具有很大的限制

(1)只能分析官方格式的崩溃日志,需要从具体的设备中导出,获取和操作都不是很方便

(2)符号化的结果也是没有具体的行号信息的,也经常会出现符号化失败的情况。

实际上, Xcode的Organizer内置了symbolicatecrash工具,所以开发者才可以直接看到符号化的崩溃堆栈日志。

2、atos

更普遍的情况是,开发者能获取到错误堆栈信息,而使用atos工具就是把地址对应的具体符号信息找到。它是一个可以把地址转换为函数名(包括行号)的工具,执行方式如下:

atos -o executable -archarchitecture -l loadAddress address

说明:

loadAddress 表示函数的动态加载地址,对应崩溃地址堆栈中 + 号前面的地址,即0x00048000

address 表示运行时地址、对应崩溃地址堆栈中第一个地址,即0x0004fbed  ,实际上,崩溃地址堆栈中+号前后的地址相加即是运行时地址,即0x00048000+31720=0x0004fbed

执行命令查询地址的符号,可以看到如下结果:

-[ViewControllerrangeException:] (in xx)(ViewController.m:68)

三.堆栈符号化原理

那么,如果我们自己来符号化堆栈,又该怎么实现呢?这里需要处理两种符号,包括用户符号和系统符号。

1.      用户堆栈的符号化

符号化的依据来自dSYM文件, dSYM文件也是Mach-o格式,我们按照Mach-o格式一步一步解析即可。


从图上我们可以大概的看出Mach-O可以分为3个部分

(1)Header

(2)Segment

(3)section

如图所示,header后面是segment,然后再跟着section,而一个segment是可以包含多个section的。

我们把dSYM文件放入可视化工具:


该dSYM文件包含armv7和arm64两种架构的符号表,我们只看armv7(arm64同理),它偏移64,直接定位到64(0x00000040),这里就是上面的Mach Header信息

 

跟我们符号表有关的两个地方,一是”LC_SYMTAB”, 二是“LC_SEGMENT(__DWARF)” -> “Section Header(__debug_line)”。

LC_SYMTAB信息


定位地址: 偏移4096+ 64(0x1040),得到函数符号信息模块”Symbols”,把函数符号解析出来,比如第一个函数: “-[DKDLicenseAgreeementModel isAuthorize]”对应的内存地址:模块地址+43856

 

“__debug_line”模块

这个模块里包含有代码文件行号信息,根据dwarf格式去一个一个解析

首先定位到SEGMENT:LC_SEGMENT(__DWARF),再定位到Section:__debug_line


它的偏移值:4248608,  4248608+ 64 = 0x40D460,定位到“Section(__DWARF,__debug_line)”

这里面就是具体的行号信息,根据dwarf格式去解析


解析出来的结果如下:


第一列是起始内存地址,第二列是结束内存地址,第三列是对应的函数名、文件名、行号信息,这样我们捕获到任意的崩溃信息后,都可以很轻松的还原了。

 

上面解析出来的Object-C符号倒没什么问题,但如果是C++或者Swift的符号就还需要特殊处理

Swift符号:

Swift函数会进行命名重整(namemangling),所以从dSYM中解析出来的原始符号是不太直观的

 

我们使用”swift-demangle”来还原:swift-demangle –simplified originName,结果如下:



C++符号:

C++函数也会进行命名重整(namemangling),所以从dSYM中解析出来的原始符号如下:


我们使用”c++filt ”来还原: c++filt originName,结果如下:

 

2.      系统堆栈的符号化

未解析形式:


解析后:

 

Apple没有提供系统库符号表的下载功能,我们可以通过真机来获取

当把开发机连到MAC时,会首先把该机型的符号拷贝到电脑上


“Processing symbol files”做的事情就是把系统符号拷贝到电脑,拷贝地址:

       ~/Library/Developer/Xcode/iOS DeviceSupport

 

但这样有个缺陷,那就是你真机的iOS版本不会足够多,包含所有版本,所以系统符号会有缺失,另一个办法就是下载各种iOS固件,从固件中去解析。

四.结语

    在实际的项目开发中,崩溃问题的分析定位都不是采用这种方式,因为它依赖于系统记录的崩溃日志或错误堆栈,在本地开发调试阶段,是没有问题的。

如果在发布的线上版本出现崩溃问题,开发者是无法即时准确的取得错误堆栈。一般地,开发者都是接入第三方的崩溃监控服务(如网易云捕),实现线上版本崩溃问题的记录和跟踪。


2014-10-08 14:19:12 totogo2010 阅读数 41507

要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件。这个文件包含了.DSYM文件。

我一般的做法是,发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了。

这个文件在哪呢?打开XCode->菜单Window->Organizer,在编译成功的文件上右键,就能打开了。


两种比较麻烦的方法。

第一种方法:

使用dwarfdump命令

dwarfdump --uuid xx.app.dSYM     用来得到app的UUID。
dwarfdump --lookup 0x12b45d -arch armv7 xx.app.dSYM  使错误的日志能看懂,把相应的内存地址对应到正确的地方。
如果一开始dwarfdump命令不能用的话,要先装Command Line Tools,这个在设置里面能下载(cmd+“,”打开设置)。另外还必须在进入.DSYM所在文件夹。

使用dwarfdump需要安装Command Line Tools,XCode里设置下载。而且需要进入.DSYM所在文件夹里进行操作。


第二种方法:

使用xcrun atos命令

atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x00062867


下面重点推荐下这个方法,方便快捷

第三方法:可视化工具

下面这是我的项目里通过友盟统计到的崩溃日志,如果光看这些日志报告的话,是不会知道是哪行代码引起的。

使用方法是把对应版本的.xcarchive文件拖到工具。对比UUID和友盟里日志是否一致,一致就把错误的地址信息拷贝到箭头处。点击分析。

即可得出具体代码崩溃位置。很简单吧。


dSYM 文件分析工具 http://answerhuang.duapp.com/index.php/2014/07/06/dsym_tool/

这是这位博主answer-huang开发了一个工具,专门用来快速定位崩溃日志的代码。感谢这位仁兄的提供这么方便的工具。

工具代码还是开源的:https://github.com/answer-huang/dSYMTools

工具下载地址:http://pan.baidu.com/s/1bnkxPvT

百度网盘的下载地址容易失效,我上传csdn下载里,当然是免积分下载了。

地址:http://download.csdn.net/detail/totogo2010/8012367



2017-10-24 14:26:00 wxs0124 阅读数 1498

在XCode8时代创建了一个Swift的项目使用的是StoryBoard开发,
升级到XCode9之后,今天打开的时候,一点击StoryBoard就会崩溃

看了崩溃日志:

UNCAUGHT EXCEPTION (NSInternalInconsistencyException): Could not find class named UIImage

意思说是找不到一个名为UIImage的类
这样根本无从下手

几经周折,找到解决办法:

1,打开storyboard的源码格式
(control+点击 —> Open As —> Source Code)

2,找到tabbar标签,把下图所示的绿圈中的 backgroundimage = “TabBarBackground”删除,保存,重启 。 解决!
这里写图片描述

iOS Swift Crash的捕获

阅读数 799

没有更多推荐了,返回首页