解析UMeng的错误分析

今天在友盟的错误分析里面找到了一个这样的错误:

Application received signal SIGSEGV
(null)
(
	0   CoreFoundation                      0x2ef6dfeb  + 154
	1   libobjc.A.dylib                     0x3971cccf objc_exception_throw + 38
	2   CoreFoundation                      0x2ef6df15  + 0
	3   appname                          0xcc979 appname + 821625
	4   libsystem_platform.dylib            0x39d43f8b _sigtramp + 34
	5   UIKit                               0x31842261  + 44
	6   UIKit                               0x31842261  + 44
	7   UIKit                               0x31842261  + 44
	8   UIKit                               0x318ab1d9  + 256
	9   UIKit                               0x3182d97f  + 142
	10  UIKit                               0x318aaefd  + 128
	11  UIKit                               0x31808115  + 312
	12  UIKit                               0x31808407  + 106
	13  UIKit                               0x31884c37  + 46
	14  Foundation                          0x2f94d163 __NSFireDelayedPerform + 414
	15  CoreFoundation                      0x2ef391b7  + 14
	16  CoreFoundation                      0x2ef38dcf  + 782
	17  CoreFoundation                      0x2ef3716b  + 1210
	18  CoreFoundation                      0x2eea1f0f CFRunLoopRunSpecific + 522
	19  CoreFoundation                      0x2eea1cf3 CFRunLoopRunInMode + 106
	20  GraphicsServices                    0x33da6663 GSEventRunModal + 138
	21  UIKit                               0x317ed16d UIApplicationMain + 1136
	22  veryWallen                          0x85613 veryWallen + 529939
	23  libdyld.dylib                       0x39c29ab7  + 2
)

dSYM UUID: 76634C55-B73F-303D-BA7C-511D5B84D45A
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: veryWallen
Base Address: 0x0008b000
Application received signal SIGSEGV
(null)SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的,那么上面所说的崩溃信息基本就能定性为内存被释放啦?问题是在哪里崩溃的呢,完全不知道啊,所以只能往里找了。使用showinfinder进入
/Users/username(电脑名)/Library/Developer/Xcode/Archives/这个文件夹,你会看到你打包时生成的xcarchive文件,当然你得用Archives来打包。然后来查找正确的包吧,也就是崩溃程序的这个包的dSYM UUID必须和上面崩溃信息的一样。

打开终端,输入cd 然后拖进
xcarchive文件吧,记得加上/dSYMs然后回车,这样你就进入了/dSYMs的目录了,再输入
dwarfdump --uuid appname.app.dSYM

命令,可别脑子坏掉的也输appname就成,然后你就能看到

armv7 和 armv7s的 两个UUID了,对比下就能知道是否是这个包了,不是就继续试直到找到位置

当你找到是哪个包了在来看下一步。。。

看看这句
	3   appname                          0xcc979 appname + 821625

这就是崩溃时调用的地方,在终端继续输入

dwarfdump --arch=armv7 --lookup 0xcc979 对应的包的路径/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname


就会得出结果,如果你前面没有敲错,那么你应该能看到不一样的Log信息,不是么,

看一下结果:发现有AT_name、Line table dir :、Line table file,没错,你能找到了出错的文件,是哪一行。。。

于是剩下的就靠你自己判断了。。。

今天到此为止!!!

还不明白看这个,我也是在紧跟前人的脚步
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/

感谢先驱们,
时间: 2024-08-07 19:48:09

解析UMeng的错误分析的相关文章

[转]UMeng的错误分析

今天在友盟的错误分析里面找到了一个这样的错误: Application received signal SIGSEGV (null) ( 0 CoreFoundation 0x2ef6dfeb + 154 1 libobjc.A.dylib 0x3971cccf objc_exception_throw + 38 2 CoreFoundation 0x2ef6df15 + 0 3 appname 0xcc979 appname + 821625 4 libsystem_platform.dyli

手写CrashHandler实现UncaughtExceptionHandler拦截android异常

手写CrashHandler实现UncaughtExceptionHandler拦截android异常 作者:码字员小D 有点复杂,虽然知道原理,但是并不好从哪开始写了...... 首先这是个需要在整个app运行状态中都需要存在的对象,所以需要在application里初始化这个类,并且这个类实例~~~慢着!发现这里代码有疑问,application中只在oncreate方法里面初始化 public class CrashApplication extends Application { @Ov

iOS Crash解析工具

现状 面对dwarfdump和symbolicatecrash相继失效的问题,要么就像六脉神剑一样,时灵时不灵的,而atos使用起来相对繁琐的问题.我们开发了Symbolicatecrash,一个Mac软件,可以方便地解析crash,目前支持apple原生的crash文件格式和Umeng crash格式. 为什么要开发这个软件呢?主要有两个原因: Xcode自带的symbolicatecrash命令使用繁琐,并且经常发生atos可以成功地解析,而symbolicatecrash总能神奇地做到什么

IOS崩溃日志解析(crash log)

IOS的应用程序少不了crash,互联网统计分析工具友盟有一项目错误分析的功能,专门用于应用程序崩溃日志统计,最近研究友盟上统计到的崩溃日志,在此对崩溃日志做一个简单的总结. IOS崩溃日志分类: 一.低内存崩溃:IOS设备检测到低内存时,虚拟内存系统发出通知请求应用释放内存.这些通知发送到所有正在运行的应用和进程,试图收回一些内存.如果内存使用依然居高不下,系统将会终止后台线程以缓解内存压力.如果可用内存足够,应用将能够继续运行而不会产生崩溃报告.否则,应用将被iOS终止,并产生低内存崩溃报告

离奇“undefined reference”错误分析与解决方案

离奇“undefined reference”错误分析与解决方案 “undefined reference to XXX”是一类挺常见的链接错误,原因通常是链接时找不到声明成extern类型的函数的定义点.不过这次遇到的undefined reference中的XXX函数明明在一个库中定义,而且该库明明已经在命令行用-l指定了,ld –verbose也显示能找到该库文件. Table of Contents 1 快速解决方案 2 从extern说起 3 链接时符号定位 4 解决方案背后的门道 4

【连载】数据库审计产品常见缺陷(4)数据库对象解析错误

继上期为大家介绍了有关数据库审计多语句无法有效分割的问题,本期,安华金和围绕数据库对象解析错误分析数据库审计产品常见缺陷.数据库审计产品中一个重要需求是要有效记录下来SQL语句的操作类型.访问对象:根据这些操作类型和访问对象,审计产品可以有效地制订告警策略,可以有效地根据操作类型.访问对象进行事后的追踪与检索.我国相关部门的数据库审计产品标准中要求:应对数据库网络访问对象的名称进行准确审计,包括数据库服务器名称.IP名称.数据库名称.表.视图.序列.包.存储过程.函数.库.索引和触发器等. 目前

Android 开源项目android-open-project工具库解析之(二) 高版本向低版本兼容,多媒体相关,事件总线(订阅者模式),传感器,安全,插件化,文件

六.Android 高版本向低版本兼容 ActionBarSherlock 为Android所有版本提供统一的ActionBar,解决4.0以下ActionBar的适配问题 项目地址:https://github.com/JakeWharton/ActionBarSherlock Demo地址:https://play.google.com/store/apps/details?id=com.actionbarsherlock.sample.demos APP示例:太多了..现在连google都

快速定位错误代码!友盟错误分析放大招

新版错误分析 错误分析是友盟为移动开发者提供的 Crash 收集和分析的工具,能够帮助开发者监测 App 在移动设备上的运行状况,及时发现并解决错误,提升 App 的稳定性.11月,新版错误分析全面上线,功能有很大的提升,友盟新版错误分析力求为开发者提供优质完美的体验与服务! 新版错误分析的功能 1.可以按照错误类型.应用版本筛选错误. 2.可以根据不同的条件为错误添加标签,便于快速分类及查找错误. 3.安卓可以通过上传 mapping 文件来定位到 Crash 的具体位置.IOS 可以通过下载

JSON 解析中遇到的坑😭

最近做加解密遇到一个很"奇葩的问题",解析服务端加密后的字符串 序列化 时一直报错 "json解析失败:Error Domain=NSCocoaErrorDomain Code=3840 "Garbage at end." UserInfo={NSDebugDescription=Garbage at end.}" 既然出现问题就开始找原因,根据错误分析原因,大概是 JSON 格式字符串有问题,搜了很多答案,被误导了. p.p1 { margin