dSYM atos crash log 定位到代码行的方法(转)

作iOS开发的时候，经常会遇到crash，须要分析call stack的时候。
有时候App在别人的设备崩溃，把crash report在本身的机器上打开，Xcode没有自动的进行符号化。
这时候就须要本身去把地址解析成符号。
大前提是，必须有相同版本App对应的.dSYM文件。
这时候打开Terminal，进入到build/Debug-iphoneos
使用命令:
$atos -arch arm7 -o XXX.app/XXX 0xabcdef
XXX是你的App名字，用须要解析的地址替换上面的0xabcdef
arm7是编译App时所用的Architecture，也多是arm6，若是在simulator上的App，这个位置应该用i386

 http://stackoverflow.com/questions/5175990/ambiguous-iphone-crash-report

 

搞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信息能够被正确地拿到。

 

 

 

 

 

当你编译一个Objective-C程序时，代码被转换成2进制文件。可是和Java等其它语言不一样，编译没法经过时，无法看出是哪里出的问题。可是，编译时会生成一个dSYM包。它能把编译崩溃报告和代码匹配起来，从而肯定问题所在。
问题是dSYM包必须和二进制文件匹配，因此每次代码重建和版本变化时都要附带重建dSYM包。这可够麻烦的。为此我写了个脚本，它能把dSYM包移入文件目录里，生成一个叫“dSYM”的目录项。此外，该脚本还能检查并保存GIT里的包。为了防止2个包重名，脚本以生成时间来命名每一个dSYM包。
故障检查
脚本的第一任务是检查可否调试。

if [ "$BUILD_STYLE" == "Debug" ]; then
echo "Skipping debug"
exit 0;
fi
脚本的第一部分是
检查该版本可否调试
。其实文件还在开发者电脑上，代码也都在，这一步能够略过了。
if [ "$EFFECTIVE_PLATFORM_NAME" == "-iphonesimulator" ]; then
echo "Skipping simulator build"
exit 0;
fi
第二步是检查版本兼容性，先无论储存代码的事。
移动文件
既然dSYM是以生成时间命名的，而且能够在开发者之间以及电脑间迁移，我把环境变量加入到文件里。
SRC_PATH=${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}
RELATIVE_DEST_PATH=dSYM/${EXECUTABLE_NAME}.$(date +%Y%m%d%H%M%S).app.dSYM
DEST_PATH=${PROJECT_DIR}/${RELATIVE_DEST_PATH}
echo "moving ${SRC_PATH} to ${DEST_PATH}"
mv "${SRC_PATH}" "${DEST_PATH}"

下一步就是创建文件当前位置到转存位置的路径。最好把路径存下来，出问题时好查看。
提交到版本控制
忙了半天，就是为了这个版本控制啊。
if [ -f ".git/config" ]; then
git add "${RELATIVE_DEST_PATH}"
git commit -m "Added dSYM file for ${BUILD_STYLE} build" \
"${RELATIVE_DEST_PATH}"
fi
只有当项目是GIT包的一部分时才触发最后这部分代码。

首先须要两个东西：
一、崩溃报告 .crash文件
    这个从手机上能够找到，经过Organizer能够导入导出
    其实须要这个文件，主要是为了找到崩溃时的栈
    友盟统计的报告中，是没有.crash文件的，只有栈信息，因此也足够
二、该应用的 .dSYM文件
    这个文件和你编译的应用二进制文件是一一对应的
    在你编译的app文件同目录下就能找到
    不过也没必要担忧上传应用到app store时的那个对应的.dSYM没保存
    在XCode4之后，有个archive功能，通常上传应用前都会archive下
    在Organizer中找到相应的archive文件，查看包内容，里面有咱们须要的.dSYM文件
两个东西准备好后执行这个命令

XML/HTML代码

1. atos -o /MyApp.dSYM/Contents/Resources/DWARF/MyApp -arch armv7 0x99999999 
   

三点说明：
一、/MyApp.dSYM/Contents/Resources/DWARF/MyApp
    就是那个.dSYM包（其实.dSYM是个包，不是二进制文件）中的文件路径
    MyApp换成你的应用名称便可
二、armv7
    根据你的应用，选择6或7
三、0x99999999
    这个是在崩溃记录中的代码地址
    就是函数的入口地址
执行后，会显示相应的函数名
由于是根据调用栈算出来的，因此只能定位到函数，没法定位到具体代码行
记得马丁福勒的“重构书”吗？里面一直强调“小函数”
这里为他提供了一个论据






http://stackoverflow.com/questions/4604843/crash-log-in-device转自:http://blog.sina.com.cn/s/blog_489ab04e010157pg.html