重点是dwarfdump --uuid命令 我们在iOS开发中会碰到的很多crash问题,如果Debug调试模式的话,我们可以往往很容易的根据log的输出定位到导致crash的原因,但对于已经上线的应用,或者是release环境包导致的crash,我们就需要一些特殊的手段来通过crash log进行分析定位了. 通过参考网上的一些资料,总结了一下,下面介绍一下通过dSYM文件以及crash log分析定位的方法. 1.导出crash log 通过Xcode的Organizer查看某台iphone

前言 我们在开发App过程中,因为连接到控制台,所以遇到问题会很容易找到问题代码.但是对于线上的App出现Crash的时候,我们不可能通过这种方式,也不现实,所以我们只能通过收集Crash信息,来解决Bug.而这种收集Crash信息并且分析定位到具体代码的第三方SDK很多.但是今天我们来自己实现一下. 收集 Crash 信息 Apple提供了NSException类来帮助我们收集异常信息. NSException is used to implement exception handling a

对于我们iOS开发者来说,最心碎的事莫过于苹果审核一个星期后上架app store,而第二天就报出闪退bug.一周前我刚经历过,而且最坑的是由于第一次做个人开发,经验不足,没有集成友盟的分析SDK,还好有几个好心同事下载了,然后果然有两台机器上出现了闪退.真是天无绝人之路,最重要的crash文件有了.下面我就来详细描述一下具体的心路历程以及分析方法. iOS app的所有崩溃记录都会记录在设备上,所以对于和我一样没有集成让用户发送崩溃报告功能的iOS开发者来说,要获得crash文件就必须先连上崩

对于我们iOS开发者来说,最心碎的事莫过于苹果审核一个星期后上架app store,而第二天就报出闪退bug.一周前我刚经历过,而且最坑的是由于第一次做个人开发,经验不足,没有集成友盟的分析SDK,还好有几个好心同事下载了,然后果然有两台机器上出现了闪退.真是天无绝人之路,最重要的crash文件有了.下面我就来详细描述一下具体的心路历程以及分析方法. iOS app的所有崩溃记录都会记录在设备上,所以对于和我一样没有集成让用户发送崩溃报告功能的iOS开发者来说,要获得crash文件就必须先连上崩

做iOS开发的时候,常常会遇到crash,需要分析call stack的时候.有时候App在别人的设备崩溃,把crash report在自己的机器上打开,Xcode没有自动的进行符号化.这时候就需要自己去把地址解析成符号.大前提是,必须有相同版本App对应的.dSYM文件.这时候打开Terminal,进入到build/Debug-iphoneos使用命令:$atos -arch arm7 -o XXX.app/XXX 0xabcdefXXX是你的App名字,用需要解析的地址替换上面的0xabcd

应用在没有发布前,可以通过打印log很方便的查看错误信息.但是发布后,就需要根据Crash文件来定位了. 将手机连接电脑,通过XCode获取Crash文件.Window ->Devices ->View Device logs 找到你需要的crash文件,右键导出该文件. http://www.cnblogs.com/smileEvday/p/Crash1.html 本文阐述了Crash的结构 crash文件 中大多是十六进制的文本,需要进行符号化才能获取更多信息. http://wufawe

xcode下载地址 https://developer.apple.com/download/more/

概述 我们都知道Xcode默认的调试器是LLDB(在此之前使用的是GDB),但是关于LLDB的debug技巧并非所有人都比较清楚,可能所有人都知道p或者po命令打印一些变量.但是实际的情况时这些还远远不够.比如说有没有一些情况下crash无法定位到有用信息,直接出现exc_bad_access,有没有遇到过每次调试一个UI就要重新run一次Xcode(话说编译时间真的影响一个UI开发者的效率). LLDB命令 po/p variable:打印变量信息or表达式 p和po有什么区别呢? 本质上两个

来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目做优化,并排除一些线上软件的 bug,因为项目中使用了友盟统计,所以在友盟给出的错误信息统计中能比较方便的找出客户端异常的信息,可是很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 7 beyond bounds [0 .. 6]' 这类错误信息,如下图所示: 遇到这种问题如果通过 objectAtIndex 去检索错误的地方那将会是一个巨大的工作量. dSY

iOS Crash 分析(文一)- 开始 1. 名词解释 1. UUID 一个字符串,在iOS上每个可执行文件或库文件都包含至少一个UUID.目的是为了唯一识别这个文件. 2. dwarfdump 苹果提供的命令行工具,其中一些功能就是查看可执行文件件或库文件的UUID 3. symbolicatecrash 一个苹果提供的脚本.可以将crash日志符号化为可读的堆栈信息. 4. atosl 苹果提供的命令行工具,可以将crash的base_address和load_address转化为可读的堆

分析crash文件必备条件:crash文件的uuid,app的uuid,dsym文件的uuid必须一致 1> crash文件的uuid为Binary Images:0x4000 - 0x1173fff后面的32个字符组成 2> 使用dwarfdump检查app的UUID.命令行格式:dwarfdump --uuid YourApp.app/YourApp 3> 用dwarfdump检查dSYM的UUID.命令行格式:dwarfdump --uuid YourApp.app.dSYM 定位

备份   文/爱掏蜂窝的熊(简书作者)原文链接:http://www.jianshu.com/p/0b6f5148dab8著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”. 序 在日常开发中,app难免会发生崩溃.简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的. 获取崩溃信息方式 在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟.云测.百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器.下面列举一些我

一.前言: 作为一个合格的iOS开发者,除了具有规范强悍的编码能力外,还应该具有过硬的查错纠错能力.在项目运行时,程序崩溃是不可避免的,遇到这个问题,有时会出现一大堆的crash日志,艹,貌似看不懂呀.其实没有那么可怕,我们可以将这些日志格式化,通过它来快速定位问题的所在,以便迅速搞定它. 二.分析: 首先我们来看一个crash日志,大略的介绍其中的几个重要的关键词: 关键词解释: 2.1. 进程信息第一部分是闪退进程的相关信息: Incident Identifier : 是崩溃报告的唯一标识

    Outline如何获得crash日志如何解析crash日志如何分析crash日志     1. iOS策略相关     2. 常见错误标识     3. 代码bug 一.如何获得crash日志 当一个iOS应用程序崩溃时,系统会创建一份crash日志保存在设备上.这份crash日志记录着应用程序崩溃时的信息,通常包含着每个执行线程的栈调用信息(低内存闪退日志例外),对于开发人员定位问题很有帮助. 如果设备就在身边,可以连接设备,打开Xcode - Window - Organizer,在

当你的应用提交到AppStore或者各个渠道之后,请问你多久会拿到crash文件?你如何分析crash文件的呢? 上传crash文件 你的应用应当有模块能够在应用程序crash的时候上传crash信息. 要么通过用户反馈拿到crash文件,要么借助自己或第3方的crash上传模块拿到crash文件. 今天要分析的场景是你拿到用户的.crash文件之后,如何符合化crash文件(Symbolicating crash logs)的3种方法.帮助尽快找到crash原因. crash文件例子 cras

一.获取Crash Log的方式 在iOS开发过程,当应用已经打包,iPhone设备通过ipa的包安装应用后,在使用过程发现crash,那么如何获取crash日志呢,现提供如下四种获取crash日志的方式: 1.打开iPhone设备的设置里面的隐私中的"诊断与用量",然后如果app崩溃了,设备会弹出提示框,用户确认之后,crash log会自动发送到苹果后台,然后用开发者账号登陆上去,可以拿到crash log. 2.将设备链接到mac或者windows上,同步到iTunes后再从电脑

iOS crash日志分析 一. 寻找crash文件:手机崩溃后的ips或者crash文件(ips文件可以直接修改成crash文件,直接改后缀名就可以了),这里说下如何拿到crash文件 1. 把运行崩溃了的手机连上** Xcode->Window->Devices ** 2. 选中手机和view device Logs 3. 找到应用程序的creash文件,把右边的copy下来,再在桌面建个.crash文件,把里面的内容copy进去就OK了 二. 配置使用命令行工具symbolicatecr

什么是 dSYM 文件 Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下,对于每一个发布版本我们都很有必要保存对应的 Archives 文件 (AUTOMATICALLY SAVE THE DSYM FILES 这篇文章

工作中难免或碰到crash,如果是开发环境,碰到简单的crash还能重现下,如果不能重现的话,我们只能去分crash文件了. 首先看下面的crash问题,说句实话一看这个我是拒绝的,这怎么找原因啊,头都大了. 68BFD825-BB35-4106-B030-772B9884FB82.png 1. 进程信息第一部分是闪退进程的相关信息. Incident Identifier : 是崩溃报告的唯一标识符. CrashReporter Key: 是与设备标识相对应的唯一键值.虽然它不是真正的设备标识

转自:http://www.cocoachina.com/industry/20140514/8418.html 转自wufawei的博客 当你的应用提交到App Store或者各个渠道之后,请问你多久会拿到crash文件?你如何分析crash文件的呢?   上传crash文件 你的应用应当有模块能够在应用程序crash的时候上传crash信息. 要么通过用户反馈拿到crash文件,要么借助自己或第3方的crash上传模块拿到crash文件.   今天要分析的场景是你拿到用户的.crash文件之