|
搞iPhone开发就要不停地发版本，随之而来的就是各种版本的crash log。如果不能好好地管理，那么开发人员很快就会在crash log和版本的海洋里迷失方向。
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信息可以被正确地拿到。 |
原文地址：http://www.acwind.net/blog/?p=1090
Bug是永远伴随着程序员们的东西，各种各样的情况造成程序crash掉也是家常便饭。Windows下的很多大型软件在崩溃的时候，都会弹出提示框，询问用户是否将crash的信息发送到软件厂商，以供软件开发商debug。App store中的软件也有这个功能，用户在使用软件的时候，如果程序崩溃，错误信息会发送到Apple的服务器中，软件的开发者们可以很方便在后台获得自己程序的crash log，供自己调试。
但随之而来的问题是，我们收到的程序崩溃调试信息多半是汇编语言一样的堆栈代码，同时这些信息并不是在我们debug的时候产生，所以看到这一串crash log的天书，常常无可奈何。Xcode很好的解决了这一问题，它所提供的Orgainzer分析器加上symbolicatecrash，可以分析二进制文件以及源代码和crashlog之间的连接，直接找出源程序中出错的代码行。方法网上到处是，本文不讨论。
但是如果使用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
输出信息如下：
