分析友盟统计的App崩溃日志

要分析崩溃日志，首先需要保留发布时的编译出来的.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 ，最后找到 [b]appName [/b]。这就是编译后的二进制文件。

2. atos -o [b]appName.app.dSYM/Contents/Resources/DWARF/appName
0x00062867 （注：文件路径）      也可以[/b]把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.

（我也是醉了。。。。。。）（谁解决了这个，欢迎留言）

本文感谢博主 容芳志