iOS Crash文件分析

具体！

1. 找到编译时生成的*.app和生成的*.app.dSYM文件（需要备份好）方法在：http://blog.csdn.net/cococoolwhj/article/details/7459064。
2. 找到崩溃日志 *.crash文件
如果你不确定*.app *.app.dSYM和*.crash是不是同一个App的 那就需要对比这三个文件的UUID。方法在http://hi.baidu.com/squirrelfly/item/b2ed784abe83a9086dc2f08c，如果确定直接到步骤4
3. 如果UUID相同你就可以进行下面的工作了
4. 先用symbolicatecrash命令或者xcode自带日志分析器 得到Crash 的内存地址，symbolicatecrash使用方法：symbolicatecrash *.crash *.app.dSYM
5. 然后用dwarfdump 命令如果运气好就能找出对于内存地址在代码中的位置，否则就悲惨了。（这个需要在命令行操作）
6. 最后就是找代码查看bug
PS：如果出现找不到symbolicatecrash 命令，请使用以下命令后就可以正常使用：
export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"
这个blog只是理清楚分析Crash思路，具体怎么做google上面很多。
推荐一下几个网址：http://wangfei0206wl.blog.163.com/blog/static/2685049520122280755746/
希望对大家有用，需要工具或者需要讨论的请联系@Anselz0

通过以上步骤大概了解怎么分析Crash文件了吧：下面详细一点

第一步

MAC上有个免费的小工具——dwarfdump，可以简便地检测出app和相应的dSYM。

使用起来很简单。分三步即可。
1> 根据crash log，得到App的UUID。UUID是个字符串，由32个字符组成。得到了UUID，你才能知道是你的哪个版本在用户的iPhone上出了问题。

2> 使用dwarfdump检查app，看哪个app是上面那个UUID。命令行格式：
dwarfdump --uuid YourApp.app/YourApp

3> 用dwarfdump检查dSYM文件是否是上面的UUID。命令行格式：
dwarfdump --uuid YourApp.app.dSYM

如果三者的UUID都是一致的，那么恭喜你，该crash log可以被正确解析出来，stack traces信息可以被正确地拿到。

第二步 

1、ios应用crash的四种类型

• 程序崩溃: 可能是最常见的,经常发生于内存访问出错,异常,或者其他的程序错误

• 内存不足: 系统因为没有足够的内存满足程序需求从而杀死程序出现这种日志.它不同于其他日志的是它没有程序各线程的堆栈信息. Rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory usage of each process is reported in terms of number of memory pages, which as of this writing are 4KB each.

• 强制退出:异常代码 0xdeadfa11. 这出现在用户在程序界面按下关机键知道出现"移动滑块关机",然后长按Home键.用户之所以这么做,很可能因为你的程序无响应,当然也不一定.

• 响应超时: 异常代码 0x8badf00d

• ios应用crash的四种类型

2、如何获取crash log
      iPhone真机上Crash文件的存储路径为：/var/mobile/Library/Logs/CrashReporter
      我们走xcode的organizer的device log中获取相应应用的crash信息文件
      选中我们关注的应用app，找到关心的异常时间的crash记录，点击右键，选择"Reveal Log in Finder"保存到dSYM文件目录下。
3、如何分析
     如果您的应用程序就是由你的xcode生成，那么自动在crash log中会对信息进行翻译，得到有效的crash信息。
     如果不是这样，按下面方面处理
     a、将crash log文件拷贝到应用程序目录下，比如：test目录下有yourapp.app、yourapp.app.dSYM文件(记住此dSYM与产生此crash log的应用版本是一致的)。
     b、执行命令：symbolicatecrash ***.crash ***.app.dSYM | less，在命令行中可以看到解释后的log信息。
    
    symbolicatecrash 命令工具的位置：
    在ios3.0及以后版本，/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources
    在ios3.0以前版本，/Developer/Platforms/iPhoneOS.platform/Developer /Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/
4、crash log分析原理
      如果程序崩溃，错误信息会发送到Apple的服务器中，软件的开发者们可以很方便在后台获得自己程序的crash log，供自己调试。但随之而来的问题是，我们收到的程序崩溃调试信息多半是汇编语言一样的堆栈代码，同时这些信息并不是在我们debug的时候产生，所以看到这一串 crash log的天书，常常无可奈何。Xcode很好的解决了这一问题，它所提供的Orgainzer分析器加上symbolicatecrash?，可以分析二 进制文件以及源代码和crashlog之间的连接，直接找出源程序中出错的代码行。
5、使用其他方法分析crash
     如果使用symbolicatecrash?无法定位到出错的代码行的话，怎么整呢？有一个办法，如下：

     首先查看crash log中的崩溃线程，假如是这样的：

     Thread 0 Crashed:
     0   libobjc.A.dylib               0x00003ec0 objc_msgSend + 24
     1   MyApp               0x000036d2 0×1000 + 9938?

     我们得到了用户发生崩溃情况的内存地址：0x000036d2?

     然后回到我们应用程序的build目录，目录下一定要包含MyApp.app 和MyApp.app.dSYM两个文件。

     在控制台使用dwarfdump命令，解析出内存地址，如： 

     dwarfdump –lookup 0x000036d2 –arch armv6 MyApp.app.dSYM

当然正常情况下crash问题，我们可以在xcode下调试分析，这种最为直接，但如果终端的ios版本过高，我们的xcode不支持，就只能升级系统+xcode+SDK方式来进行调试分析。