iOS开发如何通过UMeng的错误分析解决crash问题
来源:互联网 发布:网络歌曲 大连站 mv 编辑:程序博客网 时间:2024/05/20 13:41
友盟统计有一个很适用的功能是错误分析,通过它我们可以看到App的一些crash错误,对于定位问题有帮助,那么如何根据这些错误日志解决bug呢?
今天在友盟的错误分析里面找到了一个这样的错误:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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
1
2
Application received signal SIGSEGV
(
null
)<br><span style=
"background-color: #ff6600;"
>SIGSEGV</span>和<span style=
"background-color: #ff6600;"
>SIGBUS</span>一般是因为访问已被释放的内存或者调用不存在的方法导致的,那么上面所说的崩溃信息基本就能定性为内存被释放啦?问题是在哪里崩溃的呢,完全不知道啊,所以只能往里找了。<br>使用showinfinder进入
/Users/username(电脑名)/Library/Developer/Xcode/Archives/这个文件夹,你会看到你打包时生成的
xcarchive
文件,当然你得用Archives来打包。
然后来查找正确的包吧,也就是崩溃程序的这个包的dSYM UUID必须和上面崩溃信息的一样。
打开终端,输入cd 然后拖进
xcarchive
文件吧,记得加上/dSYMs然后回车,这样你就进入了/dSYMs的目录了,再输入
dwarfdump --uuid appname.app.dSYM
命令,可别脑子坏掉的也输appname就成,然后你就能看到
armv7 和 armv7s的 两个UUID了,对比下就能知道是否是这个包了,不是就继续试直到找到位置
当你找到是哪个包了在来看下一步。。。
看看这句
1
3 appname 0xcc979 appname + 821625
这就是崩溃时调用的地方,在终端继续输入
dwarfdump --arch=armv7 --lookup
0xcc979对应的包的路径/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname
就会得出结果,如果你前面没有敲错,那么你应该能看到不一样的Log信息,不是么,
---------------------------------------------------------------------- File: /Users/username/Library/Developer/Xcode/Archives/2014-10-16/veryWallen 14-10-16 上午11.51.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF/appname (armv7)----------------------------------------------------------------------Looking up address: 0x0000000000097525 in .debug_info... found!0x00223f5a: Compile Unit: length = 0x000021d9 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00226137)0x00223f65: TAG_compile_unit [1] * AT_producer( "Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)" ) AT_language( DW_LANG_ObjC ) AT_name( "/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking/AFHTTPSessionManager.m" ) AT_stmt_list( 0x0006eca0 ) AT_comp_dir( "/Users/paobao/Documents/veryWallen/Pods" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_major_runtime_vers( 0x02 ) AT_low_pc( 0x00096888 )0x002253ff: TAG_subprogram [10] * AT_name( "-[AFHTTPSessionManager POST:parameters:constructingBodyWithBlock:success:failure:]" ) AT_decl_file( "/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking/AFHTTPSessionManager.m" ) AT_decl_line( 179 ) AT_prototyped( 0x01 ) AT_type( {0x00224de4} ( NSURLSessionDataTask* ) ) AT_APPLE_isa( 0x01 ) AT_accessibility( DW_ACCESS_public ) AT_low_pc( 0x00097454 ) AT_high_pc( 0x000976ec ) AT_frame_base( r7 ) AT_object_pointer( {0x0022541b} )Line table dir : '/Users/paobao/Documents/veryWallen/Pods/AFNetworking/AFNetworking'Line table file: 'AFHTTPSessionManager.m' line 185, column 0 with start address 0x00000000000974a4Looking up address: 0x0000000000097525 in .debug_frame... found!0x0000c930: FDE length: 0x0000000c CIE_pointer: 0x00000000 start_addr: 0x00097454 -[AFHTTPSessionManager POST:parameters:constructingBodyWithBlock:success:failure:] range_size: 0x00000298 (end_addr = 0x000976ec) Instructions: 0x00097454: CFA=4294967295+4294967295
看一下结果:发现有AT_name、Line table dir :、Line table file,没错,你能找到了出错的文件,是哪一行。。。(也许我不小心弄错了内存地址,不过没事,知道怎么找问题就行,不是么)
于是剩下的就靠你自己判断了。。。
今天到此为止!!!
还不明白看这个,我也是在紧跟前人的脚步
http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/
0 0
- iOS开发如何通过UMeng的错误分析解决crash问题
- Umeng IOS开发应用
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- iOS通过dSYM文件分析crash
- ListView和Adapter Crash问题的分析和解决
- Iterm 2 配色, 有颜色的MAC终端
- 根文件系统的构建与分析(一)之流程分析
- 笔记:Linux常用命令(八)用户和用户组
- 正确率 召回率 F值
- 无限极数据库设计和实现逻辑分析
- iOS开发如何通过UMeng的错误分析解决crash问题
- Odoo 8.0深入浅出开发教程(四) Odoo入门
- Android ndk中进行log的方法
- CodeForces 361B
- nginx做负载均衡,怎么在有宕机情况出现时保证网站的响应速度
- android的5种布局方式
- du disk usage 磁盘使用情况 df disk free 可用磁盘情况
- CodeIgniter浓缩版笔记
- c语言概述