- 综合排序
- 最热优先
- 最新优先
- 来自专栏小菜与老鸟
Xcode编译疾如风-3.浅谈 dwarf 和 dSYM
Xcode编译疾如风-3.浅谈 dwarf 和 dSYM ? dSym指的是 Debug Symbols。也就是调试符号，我们常常称为符号表文件。 dSYM 的文件构成： MyDemo.app.dSYM └── Contents ├── Info.plist └── Resources └── DWARF dwarf 信息生成 dSYM 文件，然后通过 strip 命令去除掉 mach-o 中的调试符号化信息，以减少包体积以及不必要的源码隐私泄漏。 对于静态库，不会生成 dSYM 文件，即使设为DWARF with dSYM File。
5K21发布于 2021-05-11 - 来自专栏mukekeheart的iOS之旅
iOS学习——（转）解决iOS App打包后dSYM文件找不到的问题
dSYM文件缺失通常有两种情况**： 情况一：配置错误导致打包时没有生成dSYM文件 针对这种情况，通常是因为Project -> Build Settings下的Debug Information Format 需修改为DWARF with dSYM File后重新打包，才会生成新的dSYM文件。 ? 情况二：配置正确，但打包后找不到dSYM文件 项目文件配置正常，打包发布时dSYM文件没有正确上传到git或者管理平台，此时可以从xcarchive文件中找到dSYM文件。
2.2K30发布于 2019-09-29 - 来自专栏移动端开发
Bugly iOS自动导入符号表
-e "${CONFIG_DSYM_DEST_DIR}" ]; then mkdir ${CONFIG_DSYM_DEST_DIR} fi DSYM_FOLDER="$ {CONFIG_DSYM_SOURCE_DIR}" IFS=$'\n' echo "Scaning dSYM FOLDER: ${DSYM_FOLDER} ..." ="${DSYM_FILE_NAME}.zip" DSYM_SYMBOL_ZIP_FILE_NAME="${DSYM_SYMBOL_ZIP_FILE_NAME// /_}" DSYM_SYMBOL_ZIP_FILE=${CONFIG_DSYM_DEST_DIR}/${DSYM_SYMBOL_ZIP_FILE_NAME} if [ $CONFIG_UPLOAD_DSYM_ONLY fi # 如果只上传dSYM，直接压缩dSYM目录 zip -r -j $DSYM_SYMBOL_ZIP_FILE $dsymFile
1.9K10编辑于 2022-10-05 - 来自专栏用户6296428的专栏
有赞crash平台符号化实践
log.crash -d TheElement.App.dSYM >result.log 但是我有几个疑问： 如果App打包出来多个dSYM怎么办？ 怎么样知道crash日志，dSYM，App是正确的，可以正确做符号化，如果发现某个crash日志没有被正确符号化，怎么查这个问题？ 把dSYM丢了，相同代码再去编译一次把dSYM拿出来可以用吗？ 我们执行完后发现系统库也都符号化了，系统的dSYM在哪里，难道已经包含在App的dSYM中吗？ 崩溃日志最下面的Binary Images是干嘛的？ 针对以上这些问题，我们来做下源码分析一探究竟。 后续要遍历所有images，去找到每个二进制对应的dSYM，这样做提高了效率。 4.1 dSYM符号表保存 首先，进行符号化必不可少的一个文件就是 dSYM 符号表，我们需要保存每次正式发布的App版本对应的符号表文件。如下图所示： ?
1.8K40发布于 2020-09-21 - 来自专栏zqh
atos命令解析iOS/Mac 崩溃日志
一、拿到crash日志和dSYM文件 崩溃日志可以从xcode里打开Devices看到对应手机的一些崩溃信息，点击下图的View Device Logs就能看到崩溃日志。 获取dSYM文件在Archives里选中包，Show in Finder，显示包内容，dSYMs文件夹内有各个库的dSYM文件 如果项目archive之后没有生成dSYM文件，看看Target的Build Settings中Debug Information Format是不是DWARF with dSYM File。 二：验证下crash日志、dSYM文件的uuid是否一致 （是一个应用版本的可略过） 控制台输入命令查看dSYM文的uuid: 1、使用 cd 命令进入包含 dSYM 文件的目录 2、输入以下命令并按回车键 为例）使用atos命令去按行解析 这里在控制台输入以下命令 atos -arch arm64 -o dSYM文件存放路径/TXLiteAVSDK_TRTC_arm64.dSYM/ -l 0x1034a4000
2.6K20编辑于 2024-01-24 - 来自专栏iOS开发～
iOS_crash文件的获取及符号化(解析)
/symbolicatecrash、crash和dSYM文件放在同一文件夹里 步骤3. 执行解析命令 . 使用CrashSymbolicator.py和.dSYM 对.ips文件进行解析 python3 《CrashSymbolicator.p文件路径》 -d xxx.dSYM -p xxx.ips 运行结果会直接显示在 和 .app 文件 .dSYM是十六进制函数地址映射信息的中转文件，调试的symbols会包含在这个文件中，symbols即类名、函数名等。 Show in Finder -> 就能找到 4.4 使用 dwarfdump 查询 uuid 查询.dSYM的uuid，确保跟.ips或.crash文件的uuid一致 dwarfdump -u <dSYM dSYM文件都拷贝到待解析文件同一文件夹下 Tips3: simulator不会生成crash文件 Tips4: XCode设置生成dSYM文件，并跑到真机上，此时app产生的.ips文件会自动符号化
3.7K10编辑于 2023-10-18 - 来自专栏云原生布道专栏
【IOS开发基础系列】Xcode工具使用技巧
工具使用 1.2.1 dSYM文件 什么是 dSYM 文件 Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 Archives 文件(AUTOMATICALLY SAVE THE DSYM FILES这篇文章介绍了通过脚本每次编译后都自动保存 dSYM 文件)。 1.2.2 dSYM文件有什么作用 当我们软件 release 模式打包或上线后，不会像我们在 Xcode 中那样直观的看到用崩溃的错误，这个时候我们就需要分析 crash report 大前提是我们需要有软件版本对应的 dSYM 文件，这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。 1.2.4 dSYM工具使用 于是我抽了几个小时的时间将这些命令封装到一个应用中，也为以后解决bug提供了便利。
1.1K20编辑于 2023-10-16 - 来自专栏腾讯Bugly的专栏
iOS崩溃堆栈符号化，定位问题分分钟搞定！
一般地，Xcode项目每次编译后，都会生成一个新的.dSYM文件。因此，App的每一个发布版本，都需要备份一个对应的.dSYM文件，以便后续调试定位问题。 一般地，Xcode项目默认的配置是会在编译后生成.dSYM，开发者无需额外修改配置。 File 采用不同的编译打包方式，产生的.dSYM文件的路径也不相同。 一般地，我们推荐打包发布时，使用xcodebuild编译打包，方便.app和.app.dSYM的匹配存储，避免.app.dSYM文件丢失的情况。 文件，执行方式如下： $ symbolicatecrash XX.crash [XX.app.dSYM] > xx.sym.crash# 如果输入.dSYM参数，将只解析系统库对应的符号 使用symbolicatecrash
5.4K51发布于 2018-03-22 - 来自专栏24K纯开源
XCode日常使用备忘录
3. dSYM and App crashes dSYM是Debug Symbols的缩写，也就是说dSYM里面存储的都是可执行程序的调试符号，对于Windows下Visual Studio生成的pdb （2）macOS下利用dSYM文件调试崩溃程序。首先解释下dSYM和DWARF的关系： DWARF是一种被众多编译器和调试器使用的用于支持源代码级别调试的调试文件格式。 DWARF with dSYM 选项在标准的DWARF之外执行一个额外的步骤：创建一个单独的MyApp.app.dSYM文件，这个文件包含你的程序的所有调试符号(这个文件其实是一个包，可以通过右键->显示包内容进行查看 事实上，DWARF with dSYM选项允许你对你进行单步调试而不管可执行程序是否被剥离了调试信息(stripped)。这是可能的，这是因为gdb将会在你的程序的目录下查找.dSYM文件。 利用dSYM解析crash log的主要步骤如下： （1）在调试之前，把xxx.crash、xxx.dSYM、symbolicatecrash三个文件放到一个同一个文件夹中。
2.3K90发布于 2018-01-18 - 来自专栏iOS开发随笔
iOS 使用Xcode自带工具symbolicatecrash解析Crash文件
每次遇到闪退信息的时候都要敲一遍命令，所以趁现在写个脚本来解析闪退信息，需要的信息有文件有： dSYM文件 首先通过Xcode的菜单选项Window->Organizer拿到.xcarchive文件。 通过右键显示包内容可以看到一个dSYMs文件夹，.dSYM文件就在这个文件夹下。如果有多个dSYM文件，只选主工程的dSYM文件就行，小组件那些文件不用。 通过Xcode->Window->Organizer->Crashes下载闪退文件 复制下面的脚本，随便命个名字CrashSymbolic.sh，然后和上面的dSYM和crash两个文件一起放进同一个文件夹 -name "*.dSYM" -print) echo "找到的符号表路径：$dSYMPath" if [ ! -d $dSYMPath ] then echo "无法找到符号表dSYM文件" exit fi # .
4K10发布于 2019-12-23 - 来自专栏24K纯开源
macOS下利用dSYM文件将crash文件中的内存地址转换为可读符号
对应于Windows下的pdb文件，macOS下的crash文件解析需要用到dSYM文件。这个文件正常情况下可能不会生成，需要在XCode进行设置。 当程序崩溃时，通过symbolicatecrash对crash文件和dSYM文件中的符号进行映射，即可将crash文件中的内存地址转换为可读的字符串。以前的博文中也进行过总结，但是并没有具体实践。 这次在macOS下开发的一个程序总是崩溃，于是打算利用dSYM文件来看看到底是哪里崩溃了。 按照常规套路，先还是把*.crash文件、*.dSYM文件放到一起来，再来调用symbolicatecrash命令。先建立symbolicatecrash的软链接： ?
3.3K100发布于 2018-01-18 - 来自专栏CoderStar
iOS符号化浅析
dSYM iOS 平台中， dSYM 文件是指具有调试信息的目标文件，dSYM 中存储着文件名、方法名、行号等信息，是和可执行文件的 16 进制函数地址一一对应的，通过分析崩溃的崩溃文件可以准确知道具体的崩溃信息 dSYM 文件对于符号化过程非常重要，所以我们每次发版之后对 dSYM 文件的备份保存是非常必要的。 虽然没有 dSYM 文件时也有其他办法（可见详解没有 dSYM 文件 如何解析 iOS 崩溃日志[8]）可以帮助我们将 Crash 抓出来，但是还是不如有 dSYM 文件时来的简单快捷。 dSYM起始地址 计算崩溃地址对应 dSYM 符号表中的地址 dSYM 起止地址：0x0000000100000000，16 进制 函数偏移量：26260，10 进制 所以我们可以拿到 stack address --arch arm64 --lookup 0x100006694 iOSTest.app.dSYM 如果设备上 dSYM 文件很多，可以通过下列命令查找指定 UUID 对应 dSYM 位置 # UUID
2.6K41编辑于 2022-09-23 - 来自专栏Guangdong Qi
根据友盟统计错误分析查找线上BUG（工具篇）
工具：dSYM 文件分析工具 - answer_huang 里面有很详细的文档说明，但是下载链接已经失效不能使用了，我把一个能用的上传到QQ群文件里，QQ群 139852091 下载后是一个.app文件 图6 第一项需要一个DSYM文件，什么是DSYM文件呢，上面的链接说很清楚（图7） ? --uuid xx.app.dSYM 3.crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。 我名没有执行文件一一对应的步骤，只要知道你出BUG的DSYM文件是那个即可 DSYM文件的UUID，Slide Address都是在友盟上可以找到的，如下图（分别对应图8<1><2>标注） 错误信息指针信息是颜色不一样的指针地址像图 图8 需要注意的是我们需要在工具中选择archive类型，对应图8中<1><2>之间的 cpu Type（需要点击刚刚拖拽的DSYM文件图9） ?
3.2K10发布于 2018-09-13 - 来自专栏君赏技术博客
【已解决】Carthage 集成 Framework 提示因为 Bitcode 无法打包
配置了 DSYM 文件，听说是可以断点到源文件，可以我没测试出来。 打包的时候出问题了，多出来 Bitcode 选项。起先我以为是 Carthage 托管的默认开启 Bitcode 的原因。 经过谷歌说 DSYM 文件导致的，我就删除了所有 DSYM 文件，竟然可以打包成功。 Xcode 打包抱错如下。 ? image 解决方法 删掉 集成到工程里面的 DSYM 文件。
82420发布于 2018-09-07 - 来自专栏QQ空间开发团队的专栏
iOS 堆栈符号解析最佳实践
可以通过以下方式看看符号文件和堆栈是否是对应的 (判断 uuid 是否相同)： dwarfdump --uuid MyApp.app/MyApp dwarfdump --uuid xxx.app.dSYM Xcode 找符号文件的时候，是通过 mdfind 来找的，比如： mdfind 'com_apple_xcode_dsym_uuids = *' 该命令会把当前环境下的所有符号文件找出来。 如果你的符号文件不在此列表中，说明 mdfind 找不到我们的符号， 那么就在执行symbolicatecrash的时候显式指定dSYM文件的路径： symbolicatecrash xxx.crash xxx.dSYM/Contents/Resources/DWARF/MyApp 如果还是不能解析，试一试把 App 文件也指定： symbolicatecrash xxx.crash xxx.dSYM -o 指定符号文件，可以是 dSYM 文件，也可以是包含了符号表的可执行文件。
4.7K20发布于 2017-08-16 - 来自专栏joealzhou
友盟bug日志分析
bug log 5.png 最重要的：如果错误分析没有成功，请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。 （对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下，因此建议保留该路径下的文件，以便后续用工具分析错误。） 4、打包release发版的时候一定要生成dsYM文件，设置如下 ? bug log 7.png 二、终端命令行手动分析 1、首先还是找到友盟后台错误日志，主要分析标记出颜色的地址 ? bug log 2.png 2、查找dSYM文件步骤： Xcode --> Windows --> Organizer ，接着找到最新发布的xcarchive文件。 dSYMs --> XXX.app.dSYM --> Contents --> Resources --> DWARF 4、进到DWARF后就可以开始反编译，从而找到二进制对应的源码位置 执行代码
1.7K30发布于 2019-08-23 - 来自专栏CoderStar
Xcode 常见 CLI 工具
符号表相关 先简单介绍一下 DWARF 以及 dSYM。 DWARF 与 dSYM 的关系是，DWARF 是文件格式，而 dSYM 往往指一个单独的文件。 xx.app.dSYM > debug_info.txt # 出debug_line 的信息到文件 debug_line.txt 中 dwarfdump --debug-line xx.app.dSYM --arch arm64 --lookup 0x100006694 iOSTest.app.dSYM 更多命令可见 llvm-dwarfdump[8]。 dsymutil 作用：可以使用 dsymutil 从 二进制中 中提取 dSYM 文件以及对 dSYM 文件进行一些操作；使用场景：当dSYM文件丢失后，可以将其作为找回dSYM文件的一种方式；路径： `信息的二进制包中抽取形成`.dysm`文件 dsymutil XXX # 使用指定的符号映射更新现有的 dSYM # 处理开启bitcode选项的dsym文件 dsymutil -symbol-map
5K21编辑于 2022-09-23 - 来自专栏iOS开发攻城狮的集散地
iOS 友盟崩溃日志定位代码
工具和日志放在同一目录下 注：如果错误分析没有成功，请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。 （对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下，因此建议保留该路径下的文件，以便后续用工具分析错误。） dSYM文件 4、通过终端命令行解析崩溃日志，定位到具体代码位置。 首先通过 cd 命令进入 UMCrash 文件目录，然后执行 .
2.5K10发布于 2018-08-13 - 来自专栏LinXunFeng的专栏
解决Instruments检测内存泄漏时真机无法定位的问题
真机在使用Instruments检测内存泄漏时老是定位不到代码，显示内存地址，上网搜查后完美解决，现做下记录 问题 只显示内存地址 原因 Xcode在每次编译项目后，都会生成一个新的 dSYM 文件 ，这个文件里保存着 16 进制函数地址映射信息，显示0x10086e34b是因为我们的工程build settings 的问题�导致没有生成dSYM 文件。 解决 在自己项目下，点击Build Settings，搜索框中输入"debug in"，在Debug Information Format选择为第二项 DWARF with dSYM File 就可以了
1.5K30发布于 2018-06-29 - 来自专栏nimomeng的自我进阶
了解和分析iOS Crash Report
相应的，dSYM文件也不能用于解析其它（UUID对应的）binary信息，即便构建自于同一个源代码。 nimo: 意思就是说，同一次构建，app+dSYM+UUID是一套的。 从Xcode下载dSYM文件 在Archives organizer，选择你之前提交到App Store的Archive文件 选择Download dSYM按钮Archive Xcode会下载dSYM文件并且把他们插入到选择的 每一个dSYM文件都会有一个对应的bcsymbolmap文件。 在符号化crash report之前，你需要把那些从ITC中下载下来的dSYM文件中的晦涩信息给解析一下。 如果你使用Xcode中的下载dSYM按钮，这步解析会自动完成。 $ mdfind "com_apple_xcode_dsym_uuids == <UUID>" 如果spotlight找到了UUID对应的dSYM文件，mdfind会把dSYM文件和可能包含的归档文件的路径打印出来
2.3K20发布于 2018-09-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号