分析友盟统计的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 ，最后找到 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.

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

本文感谢博主 容芳志