要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件。这个文件包含了.DSYM文件。
这个文件在哪呢?打开XCode->菜单Window->Organizer,在编译成功的文件上右键,就能打开了。
推荐可视化工具:
下面这是我的项目里通过友盟统计到的崩溃日志,如果光看这些日志报告的话,是不会知道是哪行代码引起的。
使用方法是把对应版本的.xcarchive文件拖到工具。对比UUID和友盟里日志是否一致,一致就把错误的地址信息拷贝到箭头处。点击分析。
即可得出具体代码崩溃位置。很简单吧。(注:文件名称不要出现中文,否则选中文件闪退)
dSYM 文件分析工具 http://answerhuang.duapp.com/index.php/2014/07/06/dsym_tool/
这是这位博主answer-huang开发了一个工具,专门用来快速定位崩溃日志的代码。
工具被 容芳志 同志上传到csdn下载里,是免积分下载的。
地址:http://download.csdn.net/detail/totogo2010/8012367
遇到的问题:
Application received signal SIGSEGV
(null)
((
0 CoreFoundation 0x2d948f9b <redacted> + 154
1 libobjc.A.dylib 0x380ccccf objc_exception_throw + 38
2 CoreFoundation 0x2d948ec5 <redacted> + 0
3 appName 0x10ca11 appName + 1083921
4 libsystem_platform.dylib 0x386f3f8b _sigtramp + 34
5 UIKit 0x305ffa87 <redacted> + 62
6 UIKit 0x3037cad7 <redacted> + 94
7 UIKit 0x3037c891 <redacted> + 560
8 UIKit 0x3028403f <redacted> + 1078
9 UIKit 0x30336357 <redacted> + 214
10 UIKit 0x301e56d5 <redacted> + 316
11 UIKit 0x3015e53b <redacted> + 430
12 CoreFoundation 0x2d914255 <redacted> + 20
13 CoreFoundation 0x2d911bf9 <redacted> + 284
14 CoreFoundation 0x2d911f3b <redacted> + 730
15 CoreFoundation 0x2d87cebf CFRunLoopRunSpecific + 522
16 CoreFoundation 0x2d87cca3 CFRunLoopRunInMode + 106
17 GraphicsServices 0x32782663 GSEventRunModal + 138
18 UIKit 0x301c914d UIApplicationMain + 1136
19 appName 0x232a7 appName + 127655
20 libdyld.dylib 0x385d9ab7 <redacted> + 2
)
dSYM UUID: FAB10807-58F9-3E96-9EB2-2A93293D6141
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: appName
Base Address: 0x0002f000
Application received signal SIGSEGV :用这个软件分析后返回错误:
UmengSignalHandler (in appName) + 137 (这个蛋疼。。。。。。。)
于是我尝试了第二方法:
1. 找到提交App时使用的DYSM文件。
从 XCode->Window->Organizer 找到出现错误的那个版本,从它的 .xcarchive->dSYMs 找到 appName.app.dSYM ,继续进入,Contents->Resources->DWARF ,最后找到 appName 。这就是编译后的二进制文件。
2. atos -o appName.app.dSYM/Contents/Resources/DWARF/appName 0x00062867 (注:文件路径) 也可以把appName拷贝出来,在appName对应的目录执行下面代码,要注意对应 Binary Image 和 CPU Type
atos-arch armv7 -o appName0x00062867然而并没有解决我的问题:仍然返回
UmengSignalHandler (in appName) + 137 (此时的我心情,你能理解吗)
还没完,我又尝试了第三种方法:
1、进入dSYM文件中
2、查看app uuid 是否与友盟log中uuid一致
3.把相应的内存地址对应到正确的地方。
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
如果crash log中的dSYM UUID与本地的dYSM文件相匹配
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/lmj/Desktop/1.8.2.xcarchive/dSYMs/appName.app.dSYM/Contents/Resources/DWARF/appName (armv7)
----------------------------------------------------------------------
Looking up address: 0x000000000010ca11 in .debug_info... not found.
Looking up address: 0x000000000010ca11 in .debug_frame... not found.
本文感谢博主 容芳志