ios 崩溃 EXC_BAD_ACCESS KERN_INVALID_ADDRESS答案

【问题标题】：ios crash EXC_BAD_ACCESS KERN_INVALID_ADDRESSios 崩溃 EXC_BAD_ACCESS KERN_INVALID_ADDRESS
【发布时间】：2020-07-22 03:21:18
【问题描述】：

MyApp 在 98% 的情况下运行良好，但有时会崩溃。太随意了。

崩溃报告显示以下内容。

Thread : Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x3b1ae626 objc_msgSend + 5
1  Foundation                     0x310e2381 _netServiceMonitorCallBack + 104
2  CFNetwork                      0x302ea3b5 _QueryRecordReply(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, unsigned short, unsigned short, unsigned short, void const*, unsigned int, void*) + 324
3  libsystem_dnssd.dylib          0x3b7289d9 handle_query_response + 168
4  libsystem_dnssd.dylib          0x3b72773f DNSServiceProcessResult + 582
5  CFNetwork                      0x302ea3e5 _SocketCallBack_Mon(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 20
6  CoreFoundation                 0x30691189 __CFSocketPerformV0 + 580
7  CoreFoundation                 0x3068efaf __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
8  CoreFoundation                 0x3068e477 __CFRunLoopDoSources0 + 206
9  CoreFoundation                 0x3068cc67 __CFRunLoopRun + 630
10 CoreFoundation                 0x305f7729 CFRunLoopRunSpecific + 524
11 CoreFoundation                 0x305f750b CFRunLoopRunInMode + 106
12 GraphicsServices               0x355336d3 GSEventRunModal + 138
13 UIKit                          0x32f58871 UIApplicationMain + 1136
14 MyApp                          0x0013f813 main (main.m:16)

所有这些看起来都像内部方法。我在运行 iOS 7.1.2 的 iPad 4 上遇到了这些崩溃。我怎样才能确定下来？感谢所有帮助。

【问题讨论】：

请显示崩溃报告的顶部。尤其是异常代码。是0xbadfood吗？
No 异常代码是 0xf000000c, 0x0000000f。两次崩溃具有相同的堆栈。
使用 ExceptionHandler，在这里查看我的答案：stackoverflow.com/questions/10501358/…
@KaszásDávid 是的，但是它将如何帮助修复崩溃？现在这个崩溃来自客户端设备，通过设置异常处理程序来捕获。
@Sj。你有想过吗？您是如何找到错误的？

标签： ios objective-c ios7.1 cfnetwork

【解决方案1】：

由于指针悬空而发生此崩溃。当任何变量或对象试图访问已被释放的对象时，就会发生这种崩溃。

【讨论】：

这可能是由于向已发布的对象发送消息。但是看着堆栈跟踪，我不明白它可能出了什么问题，并且项目完全在 ARC 中。
@stevesliva 为什么这里会出现阻塞问题？ [我正在使用它们，但我遇到了类似的错误]
如果你使用一个对外部对象有强引用的块，而该块也对该块有强引用，就会出现内存泄漏。当您的块尝试访问另一个对象（第三个角色）时，您可能会认为所有对象都在同一范围内并且同时处于活动状态。但不幸的是，第三个角色可能会被解除分配。（对第三个角色的引用必须是弱的）。
这个答案是不正确的@Indrajeet 和@Sj。 “内存泄漏”与“悬空指针”相反，您在这里所拥有的内容来自悬空指针。当内存仍在分配但没有引用它（或没有引用它有用）时，就会发生内存泄漏。当指针引用已被释放的内存时，就会出现悬空指针。 EXC_BAD_ACCESS 意味着一个悬空指针，而不是前者。它也可能暗示一个未初始化的指针。（例如char* p; /* = garbage */ *p = 4; 可以做到。）
@Indrajeet 这个问题的解决方案是什么？

【解决方案2】：

这是一个老问题，但 EXC_BAD_ACCESS KERN_INVALID_ADDRESS 崩溃不是由于内存泄漏，而是由于尝试访问已释放的对象。因为被释放对象的内存现在可能被另一个不同类型的对象占用了，崩溃堆栈中的最后一行可能会产生误导，因为它并不是你程序执行路径的一部分，所以通常我们需要查找跟踪一点点。然而，@Sj 发布的堆栈跟踪基本上只包含系统调用，所以这真的很难。如果这是在调试会话中生成的，则添加“所有异常”断点可能有助于生成更多信息的堆栈跟踪。

【讨论】：

感谢您的指出。是的，这不是由于内存泄漏。 stevesliva 添加了一条有助于解决问题的评论。这是由于块和对象过早释放。这就是为什么堆栈跟踪也不清楚的原因。

【解决方案3】：

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 崩溃不是由于内存泄漏，但由于尝试访问已释放的对象。

示例：如果您使用 __weak typeof(self) weakSelf = self; 并且对象在您在块内访问它之前已被释放，您将遇到崩溃。原因 - 访问错误的内存地址，因为对象已被释放。

为了防止这种情况在块内使用__strong typeof(self) strongSelf = self;。 Nil 值将被正确处理而不会崩溃

注意：使用此代码示例可以快速工作。

#define weakify(var) __weak typeof(var) AHKWeak_##var = var;

#define strongify(var) \
_Pragma("clang diagnostic push") \
_Pragma("clang diagnostic ignored \"-Wshadow\"") \
__strong typeof(var) var = AHKWeak_##var; \
_Pragma("clang diagnostic pop")

使用示例：

weakify(self); // Remove retain cycle
[self someFunctionWithBlock:^{
    strongify(self); // Make reference to address valid

}];

【讨论】：

这是不正确的；给nilweakSelf 发消息就像在ObjC 中给任何其他nil 发消息一样，这是无操作的，可以做。如果您要向它发送多条消息，您只需要strongify 弱引用，以确保它不会在中途被释放。
可能我没有描述清楚，但你重复我的想法，我同意你的观点。
当对象被释放时，弱引用会被清零，所以使用空引用不会导致任何崩溃，因为@buildsucceeded 说它在 Objective-C 中是一个 NO-OP。