ios bitcode 机制对 dsym 调试文件的影响

今天想试试用dsym和crash文件跟踪crash信息,可是一直返回如下信息:

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib            0x23269c84 __pthread_kill + 8
1   libsystem_pthread.dylib           0x2330bb46 pthread_kill + 62
2   libsystem_c.dylib                 0x232000c4 abort + 108
3   libc++abi.dylib                   0x22d7a7dc __cxa_bad_cast + 0
4   libc++abi.dylib                   0x22d936a0 default_unexpected_handler() + 0
5   libobjc.A.dylib                   0x22d9f098 _objc_terminate() + 192
6   libc++abi.dylib                   0x22d90e16 std::__terminate(void (*)()) + 78
7   libc++abi.dylib                   0x22d905f4 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) + 0
8   libobjc.A.dylib                   0x22d9eed2 objc_exception_throw + 250
9   CoreFoundation                    0x234e831e -[__NSArrayI objectAtIndex:] + 186
10  test                              0x000791f2 __hidden#5_ (__hidden#43_:35)
11  libdispatch.dylib                 0x2316fdd6 _dispatch_call_block_and_release + 10
12  libdispatch.dylib                 0x231794e6 _dispatch_after_timer_callback + 66
13  libdispatch.dylib                 0x2316fdc2 _dispatch_client_callout + 22
14  libdispatch.dylib                 0x231826d2 _dispatch_source_latch_and_call + 2042
15  libdispatch.dylib                 0x23171d16 _dispatch_source_invoke + 738
16  libdispatch.dylib                 0x231741fe _dispatch_main_queue_callback_4CF + 394
17  CoreFoundation                    0x23594fc4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
18  CoreFoundation                    0x235934be __CFRunLoopRun + 1590
19  CoreFoundation                    0x234e5bb8 CFRunLoopRunSpecific + 516
20  CoreFoundation                    0x234e59ac CFRunLoopRunInMode + 108
21  GraphicsServices                  0x2475faf8 GSEventRunModal + 160
22  UIKit                             0x277d1fb4 UIApplicationMain + 144
23  test                              0x000797de main (__hidden#317_:14)
24  libdyld.dylib                     0x23198872 start + 2

确实是解析了不假,但是却只能得到

test                              0x000791f2 __hidden#5_ (__hidden#43_:35)这个35是对的,的确是源文件第35行出了bug,但是, hidden是什么东西?之后我又单独查看了这个dsym文件,内容如下:
----------------------------------------------------------------------
 File: /Users/Breeze/Desktop/crash/test.app.dSYM/Contents/Resources/DWARF/test (armv7)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x00000073  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x00000077)

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "__hidden#30_" )
             AT_language( DW_LANG_ObjC )
             AT_name( "__hidden#43_" )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "__hidden#41_" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x0000a0b0 )
             AT_high_pc( 0x0000a206 )

0x00000028:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a0b0 )
                 AT_high_pc( 0x0000a154 )
                 AT_name( "__hidden#45_" )

0x00000035:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a154 )
                 AT_high_pc( 0x0000a166 )
                 AT_name( "__hidden#1_" )

0x00000042:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a168 )
                 AT_high_pc( 0x0000a16e )
                 AT_name( "__hidden#2_" )

0x0000004f:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a170 )
                 AT_high_pc( 0x0000a176 )
                 AT_name( "__hidden#3_" )

0x0000005c:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a178 )
                 AT_high_pc( 0x0000a1a4 )
                 AT_name( "__hidden#44_" )

0x00000069:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a1a4 )
                 AT_high_pc( 0x0000a206 )
                 AT_name( "__hidden#42_" )

0x00000076:     NULL

0x00000077: Compile Unit: length = 0x000000db  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x00000156)

0x00000082: TAG_compile_unit [1] *
             AT_producer( "__hidden#30_" )
             AT_language( DW_LANG_ObjC )
             AT_name( "__hidden#301_" )
             AT_stmt_list( 0x000000bf )
             AT_comp_dir( "__hidden#41_" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x0000a208 )
             AT_high_pc( 0x0000a796 )

0x0000009f:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a208 )
                 AT_high_pc( 0x0000a20c )
                 AT_name( "__hidden#315_" )

0x000000ac:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a20c )
                 AT_high_pc( 0x0000a20e )
                 AT_name( "__hidden#314_" )

0x000000b9:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a210 )
                 AT_high_pc( 0x0000a212 )
                 AT_name( "__hidden#313_" )

0x000000c6:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a214 )
                 AT_high_pc( 0x0000a216 )
                 AT_name( "__hidden#312_" )

0x000000d3:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a218 )
                 AT_high_pc( 0x0000a21a )
                 AT_name( "__hidden#311_" )

0x000000e0:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a21c )
                 AT_high_pc( 0x0000a22c )
                 AT_name( "__hidden#310_" )

0x000000ed:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a22c )
                 AT_high_pc( 0x0000a2a2 )
                 AT_name( "__hidden#309_" )

0x000000fa:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a2a4 )
                 AT_high_pc( 0x0000a372 )
                 AT_name( "__hidden#308_" )

0x00000107:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a374 )
                 AT_high_pc( 0x0000a5b6 )
                 AT_name( "__hidden#307_" )

0x00000114:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a5b8 )
                 AT_high_pc( 0x0000a65c )
                 AT_name( "__hidden#306_" )

0x00000121:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a65c )
                 AT_high_pc( 0x0000a702 )
                 AT_name( "__hidden#305_" )

0x0000012e:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a704 )
                 AT_high_pc( 0x0000a714 )
                 AT_name( "__hidden#304_" )

0x0000013b:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a714 )
                 AT_high_pc( 0x0000a73a )
                 AT_name( "__hidden#302_" )

0x00000148:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a73c )
                 AT_high_pc( 0x0000a796 )
                 AT_name( "__hidden#300_" )

0x00000155:     NULL

0x00000156: Compile Unit: length = 0x00000032  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x0000018c)

0x00000161: TAG_compile_unit [1] *
             AT_producer( "__hidden#30_" )
             AT_language( DW_LANG_ObjC )
             AT_name( "__hidden#317_" )
             AT_stmt_list( 0x00000320 )
             AT_comp_dir( "__hidden#41_" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x0000a798 )
             AT_high_pc( 0x0000a7f4 )

0x0000017e:     TAG_subprogram [2]
                 AT_low_pc( 0x0000a798 )
                 AT_high_pc( 0x0000a7f4 )
                 AT_name( "__hidden#316_" )

0x0000018b:     NULL

竟然全部都是hidden!!

原来是我在用orgenizer 导出ipa时,使用了下图选项:

注意到这个 rebuild from bitcode 选项了吗?看看说明:

我选择了这个选项,之后使用导出的ipa和相应的dysm文件进行相应的操作,我们可以比较一下选和不选这个选项得到不同dysm的文件大小:

上边2个是使用 bitcode发布选项后,出现的dsym,每个之后12K。而下面那个是不使用的dsym,有2.1M。

之后查看了其他网页,有如下资料:

如果你的应用也准备启用Bitcode编译机制,就需要注意以下几点:

· Xcode 7默认开启Bitcode,如果应用开启Bitcode,那么其集成的其他第三方库也需要是Bitcode编译的包才能真正进行Bitcode编译

· 开启Bitcode编译后,编译产生的.app体积会变大(中间代码,不是用户下载的包),且.dSYM文件不能用来崩溃日志的符号化(用户下载的包是Apple服务重新编译产生的,有产生新的符号文件)

· 通过Archive方式上传AppStore的包,可以在Xcode的Organizer工具中下载对应安装包的新的符号文件

时间: 2024-12-10 16:27:57

ios bitcode 机制对 dsym 调试文件的影响的相关文章

【转】iOS平台的应用程序调试与分析

转自:看雪学院的文章 iOS平台的应用程序调试与分析 作者:zhuliang转载请保证文章完整并注明来自看雪或cd-team 本文阐述如何在iOS平台上对应用程序进行调试与分析,旨在指导新手分析iOS程序,高手请无视.内容包括软件硬件的准备.代码的解密.符号信息的获取.用gdb调试等,最后以京东LeBook为例子进行演示.1.为什么要进行调试与分析研究iOS程序有很多用处,比如:找bug或者漏洞,想知道某程序有没有漏洞或者bug.某程序能实现某功能,我想知道如何实现,如ios6发短信功能,还有比

IOS消息机制应用实例--异常处理

IOS消息机制应用实例--异常处理 最近发现了一个在项目中常用的异常处的工具NullSafe,分析了它的实现原理,不小心发现了一个小Bug,现将其分享出来,关于这篇文章的Demo已经上传至GitHub,看完如有收获,欢迎Star,如有疑问欢迎issue,大家一起学习.在IOS开发中我们可能会遇到下面的情景:服务器给我们返回得某个字段是null,比如someValue:null,这个时候我们利用第三方工具转化之后会得到someValue = <null>,这个时候如果我们判断这个someValu

iOS 签名机制

iOS 签名机制挺复杂,各种证书,Provisioning Profile,entitlements,CertificateSigningRequest,p12,AppID,概念一堆,也很容易出错,本文尝试从原理出发,一步步推出为什么会有这么多概念,希望能有助于理解 iOS App 签名的原理和流程.目的先来看看苹果的签名机制是为了做什么.在 iOS 出来之前,在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的,软件随便从哪里下载都能运行,导致平台对第三方软件难以

iOS开发系列-iOS签名机制

概述 想要了解iOS的签名机制需要有一定密码学有一定的了解.下面依次介绍的数据的加密解密.单向散列函数.数字签名.证书.iOS签名机制. 数据加密解密 在网络通信中想要防止数据被攻击者拦截,我们通常对我们的数据进行加密(通过密钥对发送的消息根据加密算法生成密文),如果传输的信息被拦截,攻击者获取到的是密文. 根据密钥的使用方法,可以将密码分为2中 对称密码 公钥密码(非对称密码) 对称密码 在对称密码中,加密.解密使用的相同的密钥.常见的对称密码算法DES.3DES.AES. DES DES是一

申请iOS发布证书.p12和描述文件.mobileprovision

iOS发布证书 用于发布到App Store,只有用iOS发布证书打包的IPA才能上架到苹果应用市场. 如果要真机调试请看发布iOS调试证书的创建教程. iOS真机调试介绍 一.创建iOS发布证书 iOS证书申请这里用到一个工具Appuploader,可以在win系统中辅助快速申请iOS证书,如果没有Mac也无所谓. 可以很快速的创建iOS推送证书 先安装好Appuploader安装教程 1.打开Appuploader,选择Certification 2.点击+ ADD类型会出现各种证书选项,根

深入浅出iOS事件机制

深入浅出iOS事件机制 2015年 04月 12日 本文章将讲解有关iOS事件的传递机制,如有错误或者不同的见解,欢迎留言指出.转载自:http://zhoon.github.io/ios/2015/04/12/ios-event.html iOS的事件有好几种:Touch Events(触摸事件).Motion Events(运动事件,比如重力感应和摇一摇等).Remote Events(远程事件,比如用耳机上得按键来控制手机),其中最常用的应该就是Touch Events了,基本存在于每个a

iOS应用的真机调试

必须条件:99美元的帐号,没有这个就不用再往下看了. 首先,登录到http://developer.apple.com/devcenter/ios/index.action,如果已经购买了iPhone Develop Program(iDP),登录进去后,页面右上角会看到如下图所示的页面: 点击第一项:iOS Provisioning Portal,然后会看到下面的页面: 点击进入Certificates,然后看到如下所示的页面: 点击图中的click here to download now,

IOS开发 - Info.plist跟pch文件的作用

IOS开发 - Info.plist和pch文件的作用 1. Info.plist和pch文件的作用 2. UIApplication的常见使用 3. AppDelegate的代理方法 4. UIApplication , AppDelegate , UIWindow , UIViewController 的关系 5. IOS程序的完整启动过程 ﹣Info.plist文件﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣我是分割线﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣ *** Bundl

iOS签名机制解析

最近遇到一个签名的问题,借机把iOS签名相关知识点研究了一下.现总结如下:(研究过程中参考了这位仁兄的博客.很全面,本文也有部分借鉴) 非对称加密 这个是签名机制的算法基础.所谓非对称加密的是相对于对称加密来说的.对称加密是加密方和解密方约定一个相同的密钥和加解密算法.只要获取了这个密钥,则可以破译加密内容.这种加密方法下,假如我要和3个人通信,就需要和三个人分别约定好3个不同的密钥,不然这三个人就没办法鉴别消息是由我本人加密的. 而非对称加密则是采用了一对密钥(私钥和公钥).通过公钥加密的内容