如何分析友盟上给出的错误分析(stack trace)
来源:互联网 发布:自动连接移动数据 编辑:程序博客网 时间:2024/06/07 09:51
面对友盟上的错误报告,怎么分析呢?怎么将错误精确到具体的位置呢?
下面讲下方法:
上图是我的一个stack trace
由于这类的崩溃信息很难再重现, 没有任何的重现步骤(也没必要花这个时间去测试),所以我们得找到发布该版本时的原始代码,可能会需要回朔到以前的SVN或者Git版本。然后找到当时上传代码时使用的DYSM文件,这文件通常在.xcarchive文件中。通过反编译这个二进制文件找到崩溃的地方。
通过终端定位到app的DYSM目录下:
1)在实用工具里打开终端,一直用cd命令打开,找到你开发包对应的文件XXXXXX.app.dSYM. 路径一般是:~/Library/Developer/XCode/Archives/YYYY-MM-DD/XXXX.app.dSYM
2)用cd打开您打包时间对应的开发包,一般名字是类似这样:XXXX 14-5-5 下午5.53.xcarchive
3)然后继续用cd命令打开,找到DEARF文件,一般是Contents/Resources/DWARF
最后在终端输入: xcrun atos -arch armv7 -o ExamdaSchool 0xaaaaa (xcrun 是去掉警告的作用)
其实对于成功生成archvie的项目, 在这个archive的包中, 是可以通过显示包内容, 看到DSYMs文件夹和一个products文件夹, 继续显示DSYMs文件夹下,可以看到一个xxx.app.DSYM文件,继续对它显示包内容,可以看到Contents/Resources/DWARF/xxxx文件, 这个文件是编译后的二进制文件,通过它可以进行反编译,从而找到二进制对应的源码位置。你只要找到DWARF文件,然后拷贝到桌面或者其它目录下,然后cd 到DWARF这个路径,然后执行xcrun atos -arch armv7 -o ExamdaSchool 0xaaaaa
下面是我执行的效果图
- 如何分析友盟上给出的错误分析(stack trace)
- c3p0 DEBUG STACK TRACE for PoolBackedDataSource.close(). 错误分析
- dump 分析模式之 INCORRECT STACK TRACE
- [Muduo网络库源码分析] (4) base/Exception_cc_h_带 stack trace 的异常基类
- GPSR的trace文件格式分析
- 对trace文件的分析
- 如何分析SQL Server中的deadlock trace
- js中stack overflow at line XX的错误分析
- NS2下的无线Trace文件分析
- ns2的trace文件分析过程
- FAQ(trace分析,常见问题分析)
- tkprof分析trace文件
- trace-clock.c 分析
- Oracle-trace文件分析
- anr trace文件分析
- Xcode的 stack trace信息
- 如何从trace文件分析网络性能(转)
- 如何打出Android程序调用stack trace
- logback(二)
- jQuery -> 获取后代元素的三种方法
- linux 下 navicat for mysql 过期解决办法
- 前景检测算法_3(GMM)
- Java Socket编程
- 如何分析友盟上给出的错误分析(stack trace)
- 红黑树--删除 算法导论笔记
- http状态码
- mysql中常用的字符串函数
- linux 下cat都正常显示,vi却显示乱码 问题解决
- 5数据包发送流程
- C++设计模式——基础概念
- WEB前端 实现生成文件 并下载
- Delphi学习笔记——方法