ios crash EXC_BAD_ACCESS KERN_INVALID_ADDRESS

2019-02-02 20:32发布

问题:

MyApp works good in 98% of the time, But sometimes it shows a crash. And its so random.

The crash report shows the following.

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)

All these look internal methods. I do experience these crashes on iPad 4 running iOS 7.1.2. How can I nail it down. All helps appreciated.

回答1:

This crash occurs due to a dangling pointer. When any variable or object is trying to access an object that's already been deallocated, this crash occurs.



回答2:

This is an old question but the EXC_BAD_ACCESS KERN_INVALID_ADDRESS crash is not due to memory leak, but due to the attempt to access an deallocated object. Because the memory of the deallocated object is possibly now occupied by another object of different type, the last line in the crash stack might be mis-leading because it's not really part of your programmed execution path, so usually we need to look up the trace a little bit. However the stack trace posted by @Sj consists basically only of system calls so it's really hard. If this is generated in a debug session, adding an "All Exceptions" breakpoint might help generate a more informative stack trace.



回答3:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS crash is not due to memory leak, but due to the attempt to access an deallocated object.

Example: if you used __weak typeof(self) weakSelf = self; and object has been released before you accessing it inside block you'll got the crash. The reason — access to wrong memory address because object was deallocated.

To prevent this use __strong typeof(self) strongSelf = self; inside the block. Nil value will be properly handled without crash


Note: use this code sample for fast work.

#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")

Usage example:

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

}];