iOS Crash报告分析

本文介绍dSYM文件的作用及如何利用它解析iOS应用Crash报告,包括获取UUID、使用atos命令和umcrashtool工具进行地址映射的方法。

相关概念

什么是 dSYM 文件

Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于

/Users/<用户名>/Library/Developer/Xcode/Archives 

对于每一个发布版本我们都很有必要保存对应的 Archives 文件。

dSYM 文件有什么作用

当我们软件 release 模式打包或上线后,不会像我们在 Xcode 中那样直观的看到用崩溃的错误,这个时候我们就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

如何将文件一一对应

每一个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID,crash 文件也有自己的 UUID,只要这三个文件的 UUID 一致,我们就可以通过他们解析出正确的错误函数信息了。

  • 查看 xx.app 文件的 UUID

terminal 中输入命令 :

$ dwarfdump --uuid xx.app/xx 
  • 查看 xx.app.dSYM 文件的 UUID
$ dwarfdump --uuid xx.app.dSYM
  • crash 文件的 UUID

crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。

上述内容原文地址:错误统计iOS :什么是 dSYM 文件和UUID

分析crash报告

以下以友盟为例,分析crash报告

crash报告

上图就是一份crash报告,提示我们是数组越界了,但是是哪里到文件,哪个数组越界了上面并没有显示,而且错误的地方都是16进制地址,我们根本看不懂,怎么办呢?
前面提到 dSYM 文件 ,该文件是一份地址映射信息的中转文件,我们现在要通过这个文件拿到映射后的函数方法等,定位到出错到地方

⚠️注意

每一个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID,crash 文件也有自己的 UUID,只要这三个文件的 UUID 一致,才可以通过他们解析出正确的错误函数信息

dSYM在哪里?

Xcode Window -> Organizer -> Archives -> crash对应版本 -> show in find -> 显示包内容 -> xx.app.dSYM

解析地址

下载 xx.app.dSYM 文件后双击(默认终端打开)

$ cd Contents/Resources/DWARF

进入DWARF文件夹目录后

$ atos -arch CPUType -o appName  address

例如 CPUType 为 arm64 项目名为GuDaShi,随便取项目的一个地址0x100250210

$ atos -arch arm64 -o GuDaShi  0x100250210

解析的结果为

解析结果

由此可知,0x100250210 的地址为我自定义的函数 requestRealDetail:success: 的回调,这样一路解析项目的地址,追踪到闪退的问题。

解析工具 umcrashtool

如果你觉得还是很麻烦的话,你也可以使用友盟提供的解析工具umcrashtool使用方法

使用步骤:

1、下载错误报告

下载错误报告

2、下载对应的dSYM和 umcrashtool,可将 umcrashtool 和错误报告放到同一个文件夹下

使用终端cd进入到分析工具和csv所在的文件夹目录下后,输入以下命令

$ ./umcrashtool xxx_错误分析_错误详情_110013.csv

如果出现下面的错误,就需要你将之前下载的dSYM文件放到 ~/Library/Developer/Xcode/. 目录下

错误

如下图所示

放置dSYM

再次运行 命令

$ ./umcrashtool   xxx_错误分析_错误详情_110013.csv

结果

解析结果

上面依此解析出来16进制地址映射出来的函数方法名,执行顺序一目了然。

### iOS Crash 原因分析和调试方法 iOS 应用程序的崩溃(Crash)通常可以分为两类:**Mach 异常**和**Unix 信号异常**。Mach 异常是底层的内核级异常,例如内存访问越界或非法指令;Unix 信号异常则包括如 `SIGABRT`、`SIGSEGV` 等,通常由程序运行时错误触发。为了全面捕获这些异常,通常采用 Mach 异常与 Unix 信号处理相结合的方式,例如使用 **plcrashreporter** 这类成熟的崩溃收集框架 [^2]。 当崩溃发生时,获取完整的调用栈信息是分析问题的关键。可以通过捕获异常并生成崩溃日志(如 `.crash` 文件),进一步解析调用栈地址与符号的映射关系,从而定位具体的代码位置。例如: ```objc // 示例:捕获未处理的异常 NSSetUncaughtExceptionHandler(&uncaughtExceptionHandle); void uncaughtExceptionHandle(NSException *exception) { NSLog(@"Exception: %@", exception); NSLog(@"Call Stack: %@", [exception callStackSymbols]); } ``` 在实际分析中,若崩溃发生在底层或 `main` 函数之前,系统可能无法提供完整的回溯栈信息。此时,可以通过重写系统异常处理机制,增强对这些异常的捕获能力 [^2]。此外,结合工具如 **Hopper** 可以对崩溃地址进行反汇编分析,将汇编指令映射到 Objective-C 方法,从而理解崩溃时的执行路径 [^1]。 调试过程中,还可以采用“现场勘探法”,即通过 Xcode 调试器在疑似崩溃点设置断点,观察运行时的寄存器状态、调用栈变化等信息,与崩溃日志进行比对,有助于发现异常行为 [^3]。例如: ```swift // 在 Xcode 中打印调用栈 Thread.callStackSymbols.forEach { symbol in print(symbol) } ``` 对于 `.crash` 文件,通常包含崩溃的模块地址范围(如 `0x4000-0x9e7fff`)和唯一标识符(如 `<8bdeaf1a0b233ac199728c2a0ebb4165>`),结合 Xcode 的 **symbolicatecrash** 工具可以将地址符号化,还原为具体的函数名或代码行号 [^4]。 ### 相关调试工具与流程 - **LLDB**:Xcode 自带的调试器,支持断点、变量查看、寄存器操作等功能,适合本地调试和远程调试。 - **Instruments**:用于性能分析,包括内存泄漏、CPU 使用率等,适用于动态追踪运行时行为。 - **Address Sanitizer (ASan)**:检测内存访问错误,如缓冲区溢出、使用已释放内存等。 - **Thread Sanitizer (TSan)**:检测多线程竞争条件和同步问题。 - **XCTest**:编写单元测试和集成测试,验证模块逻辑正确性,提前发现潜在错误。 ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值