iOS之友盟错误统计解决
2015-07-20 11:41
696 查看
http://www.cocoachina.com/ios/20150720/12627.html
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/
First
相信有很多开发者在项目中加入了友盟统计,其中一个最主要的功能就是查看线上版本统计到的错误。但是当你看到这样的信息时:
会不会有这样的想法:
这尼玛到底是什么鬼?!!
此时你可能会百度(干得漂亮!),我相信你“闪闪”的双眼肯定会看到这篇文章的:dSYM文件分析工具。具体用法我就不重复了,博主写的很详细,而且这个工具真的真的很好用!
Second
但是,友盟还统计到了这么一堆错误:
这尼玛又是什么鬼?!!怎么会这么多!
点进去看到是这样的:
用咱们上面说的工具:
这、这、这让我怎么玩,还能不能愉快的玩耍了…T_T
当然,这并不只在“Application received signal SIGSEGV (null)”这种情况下才发生,这时怎么办呢?不要捉急,少年请看这里: 解析iOS崩溃日志(crash Log)。
Third
上面这两种方法应该就可以解决大部分友盟统计到的错误了,这时你要说了,这两种方法都解决不了的怎么办?少年,此次此刻我要传授你一招江湖失传很久的绝学秘笈:把那些无法解决的错误全部勾选上,然后选择把状态标记为“处理中”,然后再标记为“已修复”,怎么样,骚年,是不是解决了!2333,但是少用为好,原因你懂的。
At last
最后感谢 answer-huang 和 裂云野 的博文分享。
最近在解析umeng错误分析日志上有了重大突破!
很显然,我们的应用免不了crash,各种各样的crash,不过大部分在提交至appstore前经过严格的“消毒”后,所剩无几了。but(这个词..)漏网之鱼总是有的嘛(貌似很多..囧)。好吧,看下文:
首先看一些这些线上app crash 信息:
SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的,余下两个就是数组越界的问题了 这些你都知道的,然后来看看具体的log信息:
Application received signal SIGSEGV
–[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
好了,相信你也看出来了,这些具体的crash log 什么都看不出来,都是一些内存地址,帧调用栈等,所以需要进一步的解析,看下文:
看一下上面的crash log,找到一句
它指出了应用名称,崩溃时的调用方法的地址,文件的地址以及方法所在的行的位置(具体请看这篇文章),接下来就要符号化(Symbolication)这句,用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配
打开终端:
OK,crash log中的dSYM UUID与本地的dYSM文件是相匹配的。好接下来就查一下0x97525这个地址是什么,
得到的结果:
看一下结果:发现有AT_name、Line table dir :、Line table file:,aha!找到了出错的地方(出错的这个文件是网上别人写的,有bug,现已不再使用)。
OK,希望能有所帮助,到此为止吧
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/
First
相信有很多开发者在项目中加入了友盟统计,其中一个最主要的功能就是查看线上版本统计到的错误。但是当你看到这样的信息时:
会不会有这样的想法:
这尼玛到底是什么鬼?!!
此时你可能会百度(干得漂亮!),我相信你“闪闪”的双眼肯定会看到这篇文章的:dSYM文件分析工具。具体用法我就不重复了,博主写的很详细,而且这个工具真的真的很好用!
Second
但是,友盟还统计到了这么一堆错误:
这尼玛又是什么鬼?!!怎么会这么多!
点进去看到是这样的:
用咱们上面说的工具:
这、这、这让我怎么玩,还能不能愉快的玩耍了…T_T
当然,这并不只在“Application received signal SIGSEGV (null)”这种情况下才发生,这时怎么办呢?不要捉急,少年请看这里: 解析iOS崩溃日志(crash Log)。
Third
上面这两种方法应该就可以解决大部分友盟统计到的错误了,这时你要说了,这两种方法都解决不了的怎么办?少年,此次此刻我要传授你一招江湖失传很久的绝学秘笈:把那些无法解决的错误全部勾选上,然后选择把状态标记为“处理中”,然后再标记为“已修复”,怎么样,骚年,是不是解决了!2333,但是少用为好,原因你懂的。
At last
最后感谢 answer-huang 和 裂云野 的博文分享。
最近在解析umeng错误分析日志上有了重大突破!
很显然,我们的应用免不了crash,各种各样的crash,不过大部分在提交至appstore前经过严格的“消毒”后,所剩无几了。but(这个词..)漏网之鱼总是有的嘛(貌似很多..囧)。好吧,看下文:
首先看一些这些线上app crash 信息:
* Application received signal SIGSEGV * Application received signal SIGBUS * -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array * -[JKArray objectAtIndex:]: index (0) beyond bounds (0)
SIGSEGV和SIGBUS一般是因为访问已被释放的内存或者调用不存在的方法导致的,余下两个就是数组越界的问题了 这些你都知道的,然后来看看具体的log信息:
Application received signal SIGSEGV
Application received signal SIGSEGV (null) ( 0 CoreFoundation 0x32f1c3ff + 186 1 libobjc.A.dylib 0x3ac17963 objc_exception_throw + 30 2 CoreFoundation 0x32f1c307 + 106 3 appname 0x14e1e1 appname + 1364449 4 libsystem_c.dylib 0x3b08bd33 _sigtramp + 34 5 appname 0x97525 appname + 615717 6 CoreFoundation 0x32e6d349 _CFXNotificationPost + 1420 7 Foundation 0x337879cd + 168 8 Foundation 0x337876c1 + 136 9 appname 0x96f2f appname + 614191 10 Foundation 0x33858915 + 16 11 Foundation 0x33798769 + 200 12 Foundation 0x33798685 + 60 13 CFNetwork 0x32bf964f + 26 14 CFNetwork 0x32bf8d33 + 54 15 CFNetwork 0x32c21013 + 18 16 CoreFoundation 0x32e62acd CFArrayApplyFunction + 176 17 CFNetwork 0x32c21473 + 74 18 CFNetwork 0x32b85461 + 188 19 CoreFoundation 0x32ef18f7 + 14 20 CoreFoundation 0x32ef115d + 212 21 CoreFoundation 0x32eeff2f + 646 22 CoreFoundation 0x32e6323d CFRunLoopRunSpecific + 356 23 CoreFoundation 0x32e630c9 CFRunLoopRunInMode + 104 24 GraphicsServices 0x36a4233b GSEventRunModal + 74 25 UIKit 0x34d7f2b9 UIApplicationMain + 1120 26 appname 0xf3df appname + 58335 27 appname 0x3578 appname + 9592 ) dSYM UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3 CPU Type: armv7s Slide Address: 0x00001000 Binary Image: appname Base Address: 0x000f7000
–[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array (null) ( 0 CoreFoundation 0x330dc3ff + 186 1 libobjc.A.dylib 0x3add7963 objc_exception_throw + 30 2 CoreFoundation 0x33027ef9 + 164 3 appname 0xcbcaf appname + 830639 4 appname 0x40bc1 appname + 261057 5 appname 0x3d297 appname + 246423 6 UIKit 0x34f36569 + 408 7 UIKit 0x34f1b391 + 1316 8 UIKit 0x34f32827 + 206 9 UIKit 0x34eee8c7 + 258 10 QuartzCore 0x34c9a513 + 214 11 QuartzCore 0x34c9a0b5 + 460 12 QuartzCore 0x34c9afd9 + 16 13 QuartzCore 0x34c9a9c3 + 238 14 QuartzCore 0x34c9a7d5 + 316 15 QuartzCore 0x34c9a639 + 60 16 CoreFoundation 0x330b1941 + 20 17 CoreFoundation 0x330afc39 + 276 18 CoreFoundation 0x330aff93 + 746 19 CoreFoundation 0x3302323d CFRunLoopRunSpecific + 356 20 CoreFoundation 0x330230c9 CFRunLoopRunInMode + 104 21 GraphicsServices 0x36c0233b GSEventRunModal + 74 22 UIKit 0x34f3f2b9 UIApplicationMain + 1120 23 appname 0xf3df appname + 58335 24 appname 0x3578 appname + 9592 ) dSYM UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3 CPU Type: armv7s Slide Address: 0x00001000 Binary Image: appname Base Address: 0x000c3000
好了,相信你也看出来了,这些具体的crash log 什么都看不出来,都是一些内存地址,帧调用栈等,所以需要进一步的解析,看下文:
看一下上面的crash log,找到一句
5 appname 0x97525 appname + 615717
它指出了应用名称,崩溃时的调用方法的地址,文件的地址以及方法所在的行的位置(具体请看这篇文章),接下来就要符号化(Symbolication)这句,用dwarfdump来检测crash log中dSYM UUID和本地的dSYM文件是否匹配
打开终端:
cd /Users/username/Library/Developer/Xcode/Archives/2013-08-30/app 8-30-13 6.19 PM.xcarchive/dSYMs dwarfdump --uuid appname.app.dSYM UUID: 9F0AEFA6-4349-30AF-8420-BCEE739DA0B4 (armv7) appname.app.dSYM/Contents/Resources/DWARF/appname UUID: 365EF56E-D598-3B94-AD36-BFA13772A4E3 (armv7s) appname.app.dSYM/Contents/Resources/DWARF/appname
OK,crash log中的dSYM UUID与本地的dYSM文件是相匹配的。好接下来就查一下0x97525这个地址是什么,
dwarfdump --arch=armv7 --lookup 0x97525 /Users/username/Library/Developer/Xcode/Archives/2013-08-30/appname\ 8-30-13\ 6.19\ PM.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname
得到的结果:
---------------------------------------------------------------------- File: /Users/username/Library/Developer/Xcode/ Archives/2013-08-30/appname 8-30-13 6.19 PM.xcarchive/dSYMs/appname.app.dSYM/Contents/ Resources/DWARF/appname (armv7) ---------------------------------------------------------------------- Looking up address: 0x0000000000097525 in .debug_info... found! 0x00359c67: Compile Unit: length = 0x000066f1 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x0036035c) 0x00359c72: TAG_compile_unit [1] * AT_producer( "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)" ) AT_language( DW_LANG_ObjC ) AT_name( "xxx/EGOImageView.m" ) AT_low_pc( 0x0009710c ) AT_stmt_list( 0x000655c1 ) AT_comp_dir( "xxx" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_major_runtime_vers( 0x02 ) 0x00359e57: TAG_subprogram [10] * AT_name( "-[EGOImageView imageLoaderDidFailToLoad:]" ) AT_decl_file( "xxx/EGOImageView.m" ) AT_decl_line( 96 ) AT_prototyped( 0x01 ) AT_APPLE_isa( 0x01 ) AT_low_pc( 0x00097490 ) AT_high_pc( 0x00097572 ) AT_frame_base( r7 ) AT_object_pointer( {0x00359e6e} ) Line table dir : 'xxx' Line table file: 'EGOImageView.m' line 99, column 2 with start address 0x00000000000974fe Looking up address: 0x0000000000097525 in .debug_frame... found! 0x0000c620: FDE length: 0x0000000c CIE_pointer: 0x00000000 start_addr: 0x00097490 -[EGOImageView imageLoaderDidFailToLoad:] range_size: 0x000000e2 (end_addr = 0x00097572) Instructions: 0x00097490: CFA=4294967295+4294967295
看一下结果:发现有AT_name、Line table dir :、Line table file:,aha!找到了出错的地方(出错的这个文件是网上别人写的,有bug,现已不再使用)。
注意:如果发现warning: unsupported file type:错误,这个问题是因为有文件或者目录的名称中包含空格,比如:2013-08-30/appname 8-30-13 6.19 ,所以,需要转义一下:2013-08-30/appname\ 8-30-13\ 6.19\ PM.xcarchive
(参看此文章)OK,希望能有所帮助,到此为止吧
相关文章推荐
- 一些好的学习iOS帖子
- IOS开发-NSMutableAttributedString 富文本的使用
- 高仿一元云购IOS应用源码项目
- iOS设计模式-外观
- JSPatch – 动态更新iOS APP
- iOS 获取Mac Address
- iOS获取定位的方式(百度和系统自带的定位方式)
- 5、iOS传值的方法-Block反向传值
- iOS开发-Day5-C的复习
- IOS工程自动打包并发布脚本实现
- 高仿一元云购IOS应用源码项目
- 高仿一元云购IOS应用源码项目
- 非常不错的点餐系统应用ios源码完整版
- 【iOS实现一个颜色渐变的弧形进度条】
- iOS开发点滴-添加阴影效果
- iOS开发点滴-添加阴影效果
- IOS开发学习笔记
- iOS开发之沙盒机制(SandBox)
- IOS - 用户信息默认界面
- iOS按钮显示的字体模糊的问题