作者：hacker发布时间：2022-07-10分类：黑客教程浏览：104评论：4
Crash原因
Crash原因有共性，归纳起来有：
�6�1 内存管理错误
�6�1 程序逻辑错误
�6�1 SDK错误 （部署版本 编译版本）
�6�1 主线程阻塞
内存管理错误
内存管理是iPhone开发所要掌握的最基本问题，特别是使用引用计数手动管理内存的情况。内存管理错误包括：
�6�1 内存泄漏：未释放不会再使用对象。比如alloc忘记release,malloc忘记free。可用XcodeProduct菜单下的Analyze功能来解决该问题；
�6�1 引用出错：引用已经被释放的对象指针。很多“莫名其妙”的Crash都是由于窗体经历的生命周期所导致的（viewDidUnload、viewDidLoad），在iOSSimulator里模拟内存警告就可以解决该问题；
�6�1 内存警告：App使用的内存超出设备的限制，iOS将强制挂起App，强制挂起iOS是不会记录Crashlog，Flurry也无法记录。内存泄漏、快速/大量的分配内存都可能导致内存警告，这时候应该尽可能的释放不需要的资源。通过Instruments-Allocations里的Heapshot功能能够找出哪些资源未被释放。
WWDC 2012的Session242 - iOS App Performance_ Memory是专门讨论内存管理这个话题。
程序逻辑错误
数组越界、堆栈溢出、并发操作、逻辑错误。扎实的编码基础、严谨细致的工作习惯、清晰的思路可以避免这类错误；
SDK错误
这个错误出现的现象是有的设备运行正常，有的会Crash。原因是未找到框架、类、方法、属性。比如：用iOS5.0 SDK编译并运行在iOS4.0的设备上，5.0的Twitter框架在4.0的设备上找不到。这种问题常出现在用苹果新发布的Xcode编译原有的工程。
未找到框架的解决办法是：部署版本= 编译版本。iOS框架向后兼容做的很棒，部署版本 编译版本一般不会出现问题。
未找到类、方法、属性的解决办法是：先判断是否存在再使用
if(NSClassFromString(@"MFMailComposeViewController"))
respondsToSelector:
主线程阻塞
主线程阻塞超过10s，iOS将强制挂起App。把长时间的任务放到后台线程去执行，可使用NSThread,NSOperation, dispatch。WWDC2012的Session235 - iOS App Performance_ Responsiveness有详细的介绍。
解决Crash
思路是：定位Crash的程序代码，预测Crash原因，寻找解决方案，测试。
有多种方式可以定位Crash的程序代码：
�6�1 Debug模式时，iOSSimulator断点测试定位Crash的堆栈；
�6�1 真机连接iTunes查看Crashlog (Debug模式下)；
�6�1 通过Flurry的错误记录查看；
定位之后，就是重新思考程序上下文逻辑，并有理由的预测Crash出现的原因。预测的越多，理解的越深。
寻找解决方案的方法有：
�6�1 浏览苹果官方SDK文档，找出错误原因；
�6�1 Google搜索Crash输出的信息，重点查找行业内技术论坛：cocoachina、stackoverflow、iphonedevsdk等；
�6�1 查看历届WWDC的视频、示例代码；
�6�1 在工程里添加环境变量: NSZombieEnabled、NSDebugEnabled，输出有价值的信息；
�6�1 如果未找到任何信息，可以寻求苹果官方论坛、业内技术论坛的帮助；
测试
找到解决方案后就需要测试，测试功能输入输出的准确性、程序性能、是否引入新的bug。测试有专业的测试工程师来负责，但开发工程师不能依赖测试工程师来发现问题，尽量独立解决已知存在的问题。
由于Xcode部署工程到真机上比较耗时间，如果可以的话尽可能用iOSSimulator来测试，以减少测试的时间。
建议开发工程师有一个checklist，在产品测试时自己逐一过一下上面常见的问题，这个能够避免大部分Crash。下图是我们一个产品的FlurryError记录，那120个错误Session是测试Crash时留下的。当然这个记录是没有包括iOS将强制挂起App的情况。
一、如何获得crash日志
当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息(低内存闪退日志例外)，对于开发人员定位问题很有帮助。
如果设备就在身边，可以连接设备，打开Xcode - Window - Organizer，在左侧面板中选择Device
Logs(可以选择具体设备的Device Logs或者Library下所有设备的Device
Logs)，然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。
如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以通过iTunes Connect(Manage Your
Applications - View Details - Crash
Reports)获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS:
Providing Apple with diagnostics and usage information摘要。
考虑到并不是所有iPhone用户都允许自动发送诊断报告(crash日志)，而且对于部分提交到Apple得crash日志，开发者还需要手动去拉取，然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中，通常接入现有的crash收集工具(参考1，参考2)，或者自己编写一个进行自动化收集、解析和统计汇总。
二、如何解析crash日志
当获得一份crash日志时，我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号(.dSYM)文件。
如果处于开发调试阶段，通常Xcode都能匹配到crash日志对应的二进制文件和符号文件，所以能够帮我们自动解析。
如果处于测试阶段，测试人员已经安装了不同的版本(比如alpha、beta版本)，那么需要保存好对应版本的二进制文件和符号文件，以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志，只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下，然后将.crash文件拖放到Xcode
- Window - Organizer中左侧面板Library下的Device Logs中，即可进行解析。
如果要提交发布，那么我们通常会先执行Clean，再Build，最后通过Product -
Archive来打包。这样，Xcode会将二进制文件和符号文件归档在一起，可以通过Organizer中的Archives进行浏览。
三、如何分析crash日志
在分析一份crash日志之前，如果开发人员对于常见的错误类型有所了解，那定是极好的。
crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。
1. iOS策略
1.1 低内存闪退
前面提到大多数crash日志都包含着执行线程的栈调用信息，但是低内存闪退日志除外，这里就先看看低内存闪退日志是什么样的。
我们使用Xcode 5和iOS
7的设备模拟一次低内存闪退，然后通过Organizer查看产生的crash日志，可以发现Process和Type都为Unknown：
而具体的日志内容如下：
第一部分是崩溃信息，包括识别标识、软硬件信息和时间信息等。
第二部分是内存页分配信息，以及当前占用内存最多的进程，上图中为crashTypeDemo。
第三部分是具体的进程列表，描述着每个进程使用内存的情况以及当前状态。在较早的版本中可以在某些进程后面看到“jettisoned”字样，表明这些进程使用过多内存被终止了，而现在我们看到的是“vm-pageshortage”字样。
当iOS检测到内存过低时，它(的VM系统)会发出低内存警告通知，尝试回收一些内存;如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存;最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。
所以，我们的应用应该合理地响应系统抛出来的低内存警告通知，对一些缓存数据和可重新创建的对象进行释放，同时要避免出现内存泄露等问题。
低内存闪退是由iOS策略决定终止应用程序运行的，同样基于iOS策略的还有Watchdog超时和用户强制退出。
1.2 Watchdog超时
Apple的iOS Developer
Library网站上，QA1693文档中描述了Watchdog机制，包括生效场景和表现。如果我们的应用程序对一些特定的UI事件(比如启动、挂起、恢复、结束)响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。
这份crash报告的有趣之处在于异常代码：“0x8badf00d”，即“ate bad food”。
如果说特定的UI事件比较抽象，那么用代码来直接描述的话，对应的就是(创建一个工程时Xcode自动生成的)UIApplicationDelegate的几个方法：
所以当遇到Watchdog日志时，可以检查下上图几个方法是否有比较重的阻塞UI的动作。
QA1693举的例子是在主线程进行同步网络请求。如果我们是在公司的Wifi环境下使用则一切顺利，但当应用程序发布出去面向很大范围的用户，在各种网络环境下运行，则不可避免地会出现一片Watchdog超时报告。
另一种可能出现问题的场景就是数据量比较大的情况下进行的数据库版本迁移(同样是在主线程上)，这也是促使我写这篇总结的一个直接因素。
1.3 用户强制退出
一看到“用户强制退出”，首先可能想到的双击Home键，然后关闭应用程序。不过这种场景是不会产生crash日志的，因为双击Home键后，所有的应用程序都处于后台状态，而iOS随时都有可能关闭后台进程，所以这种场景没有crash日志。
另一种场景是用户同时按住电源键和Home键，让iPhone重启。这种场景会产生日志(仅验证过一次)，但并不针对特定应用程序。
这里指的“用户强制退出”场景，是稍微比较复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时候当前应用程序会被终止掉，并且产生一份相应事件的crash日志。
通常，用户应该是遇到应用程序卡死，并且影响到了iOS响应，才会进行这样的操作——不过感觉这操作好高级，所以这样的crash日志应该比较少见。
2. 常见错误标识
2.1 Exception codes
上面“用户强制退出”的crash日志中的Exception
Codes是“0xdeadfa11”，再上面“Watchdog超时”的crash日志中的Exception
Codes是“0x8badf00d”，这些都是特有的Exception codes。
根据官方文档描述，至少有以下几种特定异常代码：
0x8badf00d错误码：Watchdog超时，意为“ate bad food”。
0xdeadfa11错误码：用户强制退出，意为“dead fall”。
0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃。
0xbad22222错误码：VoIP应用(因为太频繁?)被iOS干掉。
0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。
0xdead10cc错误码：因为在后台时仍然占据系统资源(比如通讯录)被干掉，意为“dead lock”。
2.2 Exception types
查看我们的crash分析报告邮件，会发现最经常遇到的错误类型是SEGV(Segmentation
Violation，段违例)，表明内存操作不当，比如访问一个没有权限的内存地址。
当我们收到SIGSEGV信号时，可以往以下几个方面考虑：
访问无效内存地址，比如访问Zombie对象;
尝试往只读区域写数据;
解引用空指针;
使用未初始化的指针;
栈溢出;
此外，还有其它常见信号：
SIGABRT：收到Abort信号，可能自身调用abort()或者收到外部发送过来的信号;
SIGBUS：总线错误。与SIGSEGV不同的是，SIGSEGV访问的是无效地址(比如虚存映射不到物理内存)，而SIGBUS访问的是有效地址，但总线访问异常(比如地址对齐问题);
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限;
SIGFPE：Floating Point Error，数学计算相关问题(可能不限于浮点计算)，比如除零操作;
SIGPIPE：管道另一端没有进程接手数据;
3. 代码bug
此外，比较常见的崩溃基本都源于代码bug，比如数组越界、插空、多线程安全性、访问野指针、发送未实现的selector等。如果引入Core
Data，则又有另外一些常见问题，不过这是另一个话题了。
遇到这些bug时，都有比较清楚的错误原因说明，比如“index 0 beyond bounds for empty
array”等。需要稍微注意点的是多线程问题，当一时找不到解决思路时，不妨往多线程方面考虑下。
二、解析crash logs
经网上搜索解析crash logs的三种，由于未经测试，所以没有记录下，详见可以：
经测试可用的方法为atos -o XXX.app.dSYM/Contents/Resources/DWARF/XXX -l address0 targetAddress
其中：
a、XXX是appname
b、address0是当前进程在内存中加载的起始地址，至于为什么需要这个，那就有必要去了解下ASLR
获取地址参下图：
binary Images后面第一个即为基地址（内存中加载的起始地址）
c、targetAddress就是你想要符号化的地址 ，此处一般选取如下
3 appName 0x000f462a 0x4000 + 984618
4 appName 0x00352aee 0x4000 + 3468014
以appName开头的地址
二、常见的Crash类型
1、Watchdog timeout
Exception Code：0x8badf00d， 不太直观，可以读成“eat bad food”，意思是don‘t block main thread
紧接着下面会有一段描述：
Application Specific Information：
com.xxx.yyy failed to resume in time
对于此类Crash，我们应该去审视自己App初始化时做的事情是否正确，是否在主线程请求了网络，或者其他耗时的事情卡住了正常初始化流程。
通常系统允许一个App从启动到可以相应用户事件的时间最多为5S，如果超过了5S，App就会被系统终止掉。在Launch，resume，suspend，quit时都会有相应的时间要求。在Highlight Thread里面我们可以看到被终止时调用到的位置，xxxAppDelegate加上行号。
PS. 在连接Xcode调试时为了便于调试，系统会暂时禁用掉Watchdog，所以此类问题的发现需要使用正常的启动模式。
2、User force-quit
Exception Codes: 0xdeadfa11, deadfall
这个强制退出跟我们平时所说的kill掉后台任务操作还不太一样，通常在程序bug造成系统无法响应时可以采用长按电源键，当屏幕出现关机确认画面时按下Home键即可关闭当前程序。
3、Low Memory termination
跟一般的Crash结构不太一样，通常有Free pages，Wired Pages，Purgeable pages，largest process 组成，同事会列出当前时刻系统运行所有进程的信息。
关于Memory warning可以参看我之前写的一篇文章IOS 内存警告 Memory warning level。
App在运行过程中，系统内存紧张时通常会先发警告，同时把后台挂起的程序终止掉，最终如果还是内存不够的话就会终止掉当前前台的进程。
当接受到内存警告的事后，我们应该释放尽可能多的内存，Crash其实也可以看做是对App的一种保护。
4、Crash due to bugs
因为程序bug导致的Crash通常千奇百怪，很难一概而论。大部分情况通过Crash日志就可以定位出问题，当然也不排除部分疑难杂症看半天都不值问题出在哪儿。这个就只能看功底了，一点点找，总是能发现蛛丝马迹。是在看不出来时还可以求助于Google大神，总有人遇到和你一样的Bug
三、常见的Exception Type Exception Code
1、Exception Type
1）EXC_BAD_ACCESS
此类型的Excpetion是我们最长碰到的Crash，通常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后面的"()"还会带有补充信息。
SIGSEGV: 通常由于重复释放对象导致，这种类型在切换了ARC以后应该已经很少见到了。
SIGABRT: 收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组中等会遇到此类错误。
SEGV:（Segmentation Violation），代表无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGSEGV 访问的是无效地址，而 SIGBUS 访问的是有效地址，但总线访问异常(如地址对齐问题)
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限
2）EXC_BAD_INSTRUCTION
此类异常通常由于线程执行非法指令导致
3）EXC_ARITHMETIC
除零错误会抛出此类异常
一、先分析app的崩溃的分布情况 这个需要有（iTunes connect账号），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有账号，别着急，直接走第二步。
二、打开xcode，下载崩溃日志，直接定位出问题代码行。
1. 在开发环境下定位Crash错误
1.1 普通的crash
先来看看最普通的crash
参见图1(c01.png)
当你在debug模式下运行上面的程序就会弹出上面的框。vc就帮你定位到了错误的位置。是个对零指针的操作。非常简单，不是吗。
1.2 较难定位的crash
较难定位的crash往往是由于内存错误(参见5.1 为什么程序crash时调用堆栈是乱的)。例如以下代码：
代码
char *p = new char[16];
p[10] = 0xfd;
delete[] p;
printf(p);
以上代码有两处错误，一是第2行的内存写越界，二是第4行使用被删除的指针。
但以上代码在vc的release和debug下都不会报错。这使得这类错误很难定位。
检测这一类问题可以使用BoundsChecker工具的FinalCheck模式（BoundsChecker）
用BoundsChecker检测后可得到两个错误：Write overrun(写越界) 和 Dangling pointer(使用被删除的指针)而且都精确定位到了出错的位置。是个不错的工具。
参见图2(c02.png)
参见图3(c03.png)
1.3 注意vc的输出日志
由于一些目前未知的原因（有可能是程序的错误太严重或是BoundsChecker本身的bug），BoundsChekcer有时不能正常工作。
这里vc的输出日志有时能提供一些有用的信息。
在难找的crash中，有很大一部分是引用了非法的指针。
有时在vc的输出日志里可以看到类似于这样的信息
“emule.exe 中的 0x004277b7 处最可能的异常: 0xC0000005: 读取位置 0xfeeeff62 时发生访问冲突 。”
在缺少BoundsChecker的支持时，这是一条很重要的信息。意思是说在“程序地址0x004277b7处”对“值为0xfeeeff62的指针”进行操作。
（怎么通过“程序地址0x004277b7”找到对应的代码行可参照 3.1，）
这条信息的重要性在于，这个操作只会触发一个警告，而不会导致crash，当crash真正发生时，很有可能不会在0x004277b7附近，
甚至调用堆栈都已经被写乱，让你无从下手。（参见5.1 为什么程序crash时调用堆栈是乱的）
2. 定位发布在外的版本的Crash错误
发布在外的软件crash了，往往不好调试，所以目前很多软件都有“发送错误报告”这一功能。
实现这一功能一般分以下几步：
a. 使用SetUnhandledExceptionFilter函数
使用SetUnhandledExceptionFilter设置最高一级的异常处理函数，当程序出现任何未处理的异常，都会触发你设置的函数里。具体使用可参照msdn和emule源码。
b. 使用MiniDumpWriteDump函数
在你的异常处理函数里，使用MiniDumpWriteDump把错误信息存成特定格式的文件。具体使用可参照msdn和emule源码。
c. 发送错误报告
选用一种形式把第二步产生的错误报告(.dmp)文件发送给你指定的地方。
d. 查看错误报告
这里介绍用vc查看错误报告的方法，还可以用windows debug tools这个工具看，方法见5.2 使用windows debug tools查看.dmp文件(错误报告)
查看错误报告需要有三样东西：对应release版的代码，当时编译release版所产生的.exe和.pdb文件。（这两个文件都在编译的输出目录里。）所以当程序发布时，要保留下这两个文件。
把.dmp（错误报告文件）, .pdb, .exe. 代码，在同一目录下，用vc打开.dmp 文件。
按F5运行，程序即到达crash时的状态，可以对其进行相应的分析。
一点补充：当没有“发送错误报告”的功能，或是此功能失效，以致弹出了windows的“发送错误报告”的对话框。这时其实也是有错误报告的，一般在C:Documents and Settings用户名Local SettingsTemp里的一个.dmp文件(一般只有一个.dmp)
3. 小技巧
3.1 根据程序地址找到代码位置
可按如下步骤：
a. 使程序处于停止状态。（比如程序运行时，在vc里按Ctrl+Alt+Break，或设断点使程序停下）
b. 切换到汇编状态。（Ctrl+F11）
c. 在地址栏输入程序地址，回车。
d. 可按Ctrl+F11切回代码模式。
3.2 根据消息值查看对应的windows消息
在vc的监视窗口里输入“消息值,wm”即可看到对应的消息。
3.3 查看GetLastError返回值
在vc的监视窗口里输入“@err,hr”，即可看到LastError及其解释。
3.4 在代码中暂停程序
在debug版中可以在代码中加上“AfxDebugBreak()；”以暂停程序。release版可使用 “_asm int 3;”
4. 编程小警示
4.1 慎用IsBadPtr系列函数
当使用IsBadReadPtr, IsBadWritePtr, IsBadCodePtr一系列函数时要注意，这一类函数可能并不能达到你所想要的意图。
比如下面的代码，两个返回都是false。
代码
char *p = new char[10];
bool b;
b = IsBadReadPtr(p+10, 1);
delete[] p;
char *q = new char[10];
b = IsBadReadPtr(p, 1);
所以切忌在程序中以IsBadPtr函数来判断是否可以对这个指针进行操作。这些函数只能在调试中使用，或是你确切的知道这些函数的返回值表示的是什么意义的时候。
4.2 慎用catch(...)
为了防止程序crash或是解决一个不明白的crash时，大家很容易想到一个 try{}catch(...){}来解决问题。
的确大部分时间这样不会出问题了，但这个try-catch很有可能隐藏掉在try里面的错误，而当由此错误引起其他错误时，就很难追踪到这个问题了。
所以建议尽量少用catch(...)，如果知道某一块代码会抛出异常，应该用确切的写法。比如catch(CFileException *e), catch(int e)等等。
5. 附录
5.1 为什么程序crash时调用堆栈是乱的
当内存被写乱时程序很有可能出现很难定位的crash，比如调用堆栈是乱的，或走到不存在的代码里。这里举一例
代码
class CA
{
public:
CA(){}
~CA(){}
virtual f(){}
};
void show()
{
printf("shown");
}
int main()
{
// 对像被创建删除
CA *p = new CA;
delete p;
// 一些正常的操作
int *q = new int;
int codeAddress = (int)show;
*q = (int)codeAddress;
// 调用被删除的对像，程序有可能执行到任何地方。
p-f();
}
上面代码的结果会走到show()里显示出show（这跟编译环境有关，vc2003下测试结果是这样）。如果你了解c++的vtable机制就明白这是怎么回事。
如果不明白也没关系，我下面说个大概。
首先CA对象被创建又被删除。如果此时调用p-f()多半会crash。
第二块代码可视为一些正常的操作，new了一个q，然后对它进行了一些赋值。
如果你不明白vtable机制，那你只要知道，最后一行的 “p-f();”会执行变量q所指向的变量所指向的变量所标示的地址。（这里没打错字，是两个“所指向的变量”）
这里我“心地善良”的给这个值赋上了一个合法的函数地址show。但实际程序中q所指向的变量有可能是任意值，它再指向的变量就更是任意值了。
那程序就不知道跑哪里去了。如果这个值过于离谱，那算你运气好，程序会立即crash，而你就知道错误位置在哪了。但讨人厌的是，它有可能是一个合法地址，那程序就继续走下去，
但迟早会crash，并且调用堆栈面目全非（原因牵涉到“调用堆栈的推导”的问题这里就不多说了），
到时就根本无从知道原来是调用了被删除的p对象而导致的。
5.2 使用Debugging tools for windows查看.dmp文件(错误报告)
a. 准备好程序对应的代码，exe文件，pdb文件（编译时在编译输出目录里）
b. 安装WinDbg
c. 在winDbg里把Symbol目录设在.pdb所在目录，Image目录设在.exe所在目录，code目录设到代码目录。
d. 打开.dmp文件
e. 输入命令.ecxr。（此命令使环境回到崩溃时的状态）
f. 打开调用堆栈(ALT + F6)查看Crash的位置
g. 进行分析
简介
（FinalCheck能检测出的错误列表见附录1）
BoundsChecker是一个很强大的调试工具。这里只简单介绍如何用它的FinalCheck模式定位比较难定位的错误。
FinalCheck模式简单来说就是BoundsChecker在你的代码里加一些诊断代码来检查平时比较难查出的内存越界，错误的指针使用等。
不过付出的代价就是程序跑起来会比较慢，所以在不用时最好是把FinalCheck模式关掉。特别是发布前。
一、先分析app的崩溃的分布情况 这个需要有（iTunes connect），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有，别着急，直接走第二步。 二、打开xcode，崩溃日志，直接定位出问题代码行。
标签：ioscrash定位
已有4位网友发表了看法：
访客 评论于 2022-07-10 15:01:27 回复
ception Code：0x8badf00d， 不太直观，可以读成“eat bad food”，意思是don‘t block main thread紧接着下面会有一段描述：Application S
访客 评论于 2022-07-10 10:24:51 回复
和 Dangling pointer(使用被删除的指针)而且都精确定位到了出错的位置。是个不错的工具。参见图2(c02.png)参见图3(c03.png)1.3 注意vc的输出日志由于一些目前未知的原因（有可能
访客 评论于 2022-07-10 17:39:53 回复
、挂起、恢复、结束)响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。这份crash报告的有趣之处在于异常代码：“0x8badf00d”，即“ate bad food”。如果说特定的UI事件比较抽象，那么用代码来直接描述的话，对应的就是(创建一个工程时Xco
访客 评论于 2022-07-10 19:04:11 回复
RF/XXX -l address0 targetAddress其中：a、XXX是appnameb、address0是当前进程在内存中加载的起始地址，至于为什么需要这个，那就有必要去了解下ASLR获取地址参下图