做iOS的开发者,经常都会遇到这个问题,我在这里做一下简单的分析
下面是crash log,摘自:【EXC_BAD_ACCESS 】crash报告的问题
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000009
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000027d8 objc_msgSend + 16
1 CoreLocation 0x00009e54 -[CLLocationManager onClientEventLocation:] + 556
2 CoreLocation 0x000080ba -[CLLocationManager onClientEvent:supportInfo:] + 98
3 CoreLocation 0x00008208 OnClientEvent + 16
4 CoreLocation 0x0000331a CLClientInvokeCallback(__CLClient*, CLClientEvent, __CFDictionary const*) + 42
5 CoreLocation 0x00005a4c CLClientHandleDaemonDataLocation(__CLClient*, CLClientLocation const*, __CFDictionary const*) + 204
6 CoreLocation 0x00005baa CLClientHandleDaemonData(__CFMessagePort*, long, __CFData const*, void*) + 298
7 CoreFoundation 0x000609ce __CFMessagePortPerform + 242
8 CoreFoundation 0x00034cdc __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20
9 CoreFoundation 0x00034ca0 __CFRunLoopDoSource1 + 160 CoreFoundation 0x00027566 __CFRunLoopRun + 514
11 CoreFoundation 0x00027270 CFRunLoopRunSpecific + 224
12 CoreFoundation 0x00027178 CFRunLoopRunInMode + 52
13 GraphicsServices 0x000045ec GSEventRunModal + 108
14 GraphicsServices 0x00004698 GSEventRun + 56
15 UIKit 0x0000411c -[UIApplication _run] + 396
16 UIKit 0x00002128 UIApplicationMain + 664
17 kfc 0x00002a10 0x1000 + 6672
18 kfc 0x00002984 0x1000 + 6532
这个crash报告当做一个调用堆栈进行分析。栈底是程序的入口,栈顶是程序出错的地方。
再来看下面三行
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000009
Crashed Thread: 0
第一行 Exception Type: EXC_BAD_ACCESS (SIGBUS)
EXC_BAD_ACCESS 是异常类型,这钟类型表示访问了已经被release或者不存在的对象,导致出错,有时候会运行正常,这种情况说明被release的内存,被重用了,这就是常说的僵尸信号,关于僵尸信号楼主可以看看这个下面的帖子
http://www.devdiv.com/forum.php?mod=viewthread&tid=118126。
第二行:Exception Codes: KERN_PROTECTION_FAILURE at 0x00000009
表示异常出错的代码。此处的KERN_PROTECTION_FAILURE意思如下:
操作系统不允许用户访问(读/写)的内存地址类型,地址0x00000009就是这样的类型,经常导致的原因就是使用了从来都没有被初始化的指针
第三行:Crashed Thread: 0
表示crash所在线程编号。此处为0,应该是主线程。
综合上述,应该是在给libobjc.A.dylib库的相关对象发送消息的时候,没有初始化接收消息的对象,或者该对象已经被release。如果不是楼主自己调用libobjc库,那么有可能是别的调用了,只需要分析一下堆栈信息就知道。
参考:http://stackoverflow.com/questions/3411346/how-to-diagnose-a-kern-protection-failure
转自: http://www.devdiv.com/home.php?mod=space&uid=6998&do=blog&id=7619
分享到:
相关推荐
CGImageIssueDemo 核心图形问题测试 做什么的 似乎对于iOS 11.2 +, CoreGraphics.framework发生了奇怪的... 这导致EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000 。 重现步骤 使用CGDataProviderCreateDi
Mach异常可以是EXC_BAD_ACCESS(内存访问异常)等。Mach异常是通过Mach API暴露给用户态的,可以直接通过Mach API设置thread、task、host的异常端口来捕获Mach异常,抓取Crash事件。 二、Unix Signal Unix Signal...
- **异常类型**: 常见的奔溃原因有EXC_BAD_ACCESS(内存访问错误)、EXC_CRASH(程序异常终止)、SIGABRT(应用程序自己请求退出)等,分析这些异常类型可以帮助定位问题根源。 - **线程信息**: 奔溃日志中的线程...
- **异常类型**:日志中会显示异常类型,如`EXC_BAD_ACCESS`、`SIGABRT`等,不同类型的异常对应不同的问题。 - **错误信息**:查看错误信息,如`NSException`的`reason`,有助于理解崩溃的具体情况。 - **堆栈...
在实际操作中,我们应打开这个文件,查找其中的关键信息,如错误代码(如EXC_BAD_ACCESS、SIGSEGV等),异常类型,以及可能与之相关的线程信息。同时,日志中可能还包含了崩溃前执行的最后几行代码,这对于复现问题...
1. 应用程序崩溃检测:使用信号捕获机制(EXC_BAD_ACCESS、SIGSEGV、SIGBUS等)来检测应用程序崩溃,通过崩溃日志上报脚本add to build phrase生成日志码力实时告警数据存储,从而实现在应用程序崩溃时快速定位问题...
2. **检查异常信息**:有时,崩溃日志会包含异常信息,如`EXC_BAD_ACCESS`或`SIGABRT`,这可以帮助确定问题类型。 3. **查看局部变量和状态**:如果日志包含崩溃时的变量值,可以分析这些值以确定问题所在。 4. **...
2. **异常类型**:如SIGABRT、EXC_BAD_ACCESS等,表示发生错误的类型。 3. **堆栈跟踪**:这是最重要的一部分,它列出了崩溃发生前调用的函数序列,通过分析这个序列,开发者可以找到出错的具体位置。 4. **线程信息...
//EXC_BAD_ACCESS,非ARC正常 } returnnil; } 在几个项目种试了下,没发现啥问题,想用的尽管拿去用,另外非常欢迎参与完善,目前仅替换了几个类,还有很多需要替换的,请在github中关注,工具包以增量的形式,...
`reason`字段提供了关于异常的描述,而`name`字段则指明了异常的类型,例如`NSInvalidArgumentException`或`EXC_BAD_ACCESS`等。 除了手动捕获崩溃日志,iOS还提供了其他方式获取崩溃日志,如通过Xcode的设备和...