80

MyApp works well 98% of the time, but sometimes it crashes. It's 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 like internal methods. I experience these crashes on iPad 4 running iOS 7.1.2. How can I nail it down? All help is appreciated.

h.and.h
  • 690
  • 1
  • 8
  • 26
Sj.
  • 1,674
  • 2
  • 15
  • 23
  • 1
    Show the top of the crash report please. Especially the exception code. Is it `0xbadfood`? – orkoden Sep 05 '14 at 10:14
  • No the exception code is 0xf000000c, 0x0000000f. Both crashes have the same stack. – Sj. Sep 05 '14 at 10:27
  • use an ExceptionHandler, check out my answer here: http://stackoverflow.com/questions/10501358/objective-c-getting-line-number-or-full-stack-trace-from-debugger-error/25551171#25551171 – Dávid Kaszás Sep 05 '14 at 11:25
  • @KaszásDávid Yes but how it would help in fixing the crash? Right now this crash is from a client device, which is caught by setting the Exception Handler. – Sj. Sep 05 '14 at 12:25
  • @Sj. did you ever figure it out? How did you locate the error? – KJ Price Jul 31 '15 at 01:23
  • I was not able to find the actual cause, somehow it dint happen after that – Sj. Jul 31 '15 at 01:49
  • i am also getting same issue on NSMutableDictionary * mdict_Data = [[NSMutableDictionary alloc] init]; line – Bhadresh Sonani Sep 07 '17 at 08:04

3 Answers3

73

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.

iwasrobbed
  • 46,496
  • 21
  • 150
  • 195
Indrajeet
  • 5,490
  • 2
  • 28
  • 43
  • 8
    It can be due to sending message to an already released object. But looking at the stack trace I don't understand where it might have went wrong and the project in completely in ARC. – Sj. Sep 05 '14 at 10:34
  • 2
    @stevesliva why would blocks be an issue here? [I'm using them and I get a similar error] – drpawelo Apr 22 '15 at 09:36
  • 6
    if you use a block with a strong reference to outer object which also has a strong reference to this block, there will be a memory leak. when your block try to access another object (the 3rd role), you may be thinking there are all in the same scope and alive in the same time. but, unfortunately, the 3rd role may be deallocated. (the reference to 3rd role must be weak). – Jerry Chen Sep 26 '16 at 08:29
  • 14
    This answer is incorrect @Indrajeet and @Sj. A "memory leak" is the opposite of a "dangling pointer", and what you have here results from a dangling pointer. A memory leak occurs when memory is still allocated but nothing references it (or nothing references it _usefully_). A dangling pointer occurs when a pointer references memory that has been deallocated. EXC_BAD_ACCESS implies a dangling pointer, not the former. It could also imply an uninitialized pointer. (E.g. `char* p; /* = garbage */ *p = 4;` could do it.) – OldPeculier Apr 09 '18 at 15:20
  • 1
    @Indrajeet What is the solution for this issue? – Rohit Pradhan Mar 12 '21 at 05:16
  • 1
    I am getting this on a singleton object that is always in memory? What could be the reason? – tanmoy Jan 26 '22 at 10:00
59

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.

CodeBrew
  • 6,457
  • 2
  • 43
  • 48
  • Thanks for pointing out. Yeah, it's not due to memory leak. stevesliva had added a comment which helped out. It was due to blocks and the object getting prematurely released. That's why the stack trace is also not clear. – Sj. Aug 03 '17 at 15:35
-4

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

}];
akaDuality
  • 384
  • 5
  • 6
  • 3
    This is incorrect; messaging a `nil` weakSelf is just like messaging any other `nil` in ObjC, it's a no-op and fine to do. You only need to `strongify` the weak reference if you're going to send it multiple messages, to ensure it doesn't get deallocated partway through. – buildsucceeded Aug 30 '17 at 09:17
  • Probably I hadn't described in clearly, but you repeat my idea, I agree with you. – akaDuality Aug 31 '17 at 09:49
  • 2
    Weak references get zero-ed when the object gets deallocated, so using a nilled reference won't cause any crashes, as @buildsucceeded said it's a NO-OP in Objective-C. – Cristik Sep 12 '18 at 04:42