EXC_BAD_ACCESS in objc_msgSend while "Instrument Program Flow" is enabled

Question

I've spent a few days trying to track down this issue with no luck so far.

I am trying to measure test coverage in my project, a Mac OS application developed in Objective-C with Xcode, and this means enabling "Instrument Program Flow" and "Generate Test Coverage Files" in the build settings. I believe these correspond to the -fprofile-arcs and -ftest-coverage flags in clang.

When these are enabled (although it seems only -fprofile-arcs affects this issue) the program will crash with an EXC_BAD_ACCESS exception in objc_msgSend in certain places.

When running the application itself, this happens when the first network request is returned. The backtrace contains none of my code, and appears to occur entirely within the Foundation/Cocoa frameworks. While this was annoying, I put up with toggling the build setting on/off depending on whether I was running tests or using the application.

I have now encountered what appears to be the same issue while testing. I have just written a test that includes network access and the tests fail with apparently the same exception in the same location, when instrumenting program flow.

---

I need to figure out what's causing this. The application I'm developing is for a university project, and one of the goals is to report test coverage and evaluate the testing process. This is quite difficult to do when large parts of the application can't be tested because the tests crash.

* thread #1: tid = 0x2203, 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff88ffe708 Foundation`___NSURLConnectionWillCacheResponse_block_invoke_0 + 110
frame #2: 0x00007fff88e86528 Foundation`__65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 28
frame #3: 0x00007fff88e8646c Foundation`-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 227
frame #4: 0x00007fff88e86368 Foundation`-[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 63
frame #5: 0x00007fff88ffda3c Foundation`_NSURLConnectionWillCacheResponse + 126
frame #6: 0x00007fff879f8272 CFNetwork`___delegate_willCacheResponse_block_invoke_0 + 48
frame #7: 0x00007fff87a75a7a CFNetwork`___withDelegateAsync_block_invoke_0 + 90
frame #8: 0x00007fff87b062ea CFNetwork`__block_global_1 + 28
frame #9: 0x00007fff90110154 CoreFoundation`CFArrayApplyFunction + 68
frame #10: 0x00007fff87a667e4 CFNetwork`RunloopBlockContext::perform() + 124
frame #11: 0x00007fff87a666bb CFNetwork`MultiplexerSource::perform() + 221
frame #12: 0x00007fff900f1b31 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #13: 0x00007fff900f1455 CoreFoundation`__CFRunLoopDoSources0 + 245
frame #14: 0x00007fff901147f5 CoreFoundation`__CFRunLoopRun + 789
frame #15: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #16: 0x00007fff8a660eb4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #17: 0x00007fff8a660c52 HIToolbox`ReceiveNextEventCommon + 356
frame #18: 0x00007fff8a660ae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #19: 0x00007fff92804563 AppKit`_DPSNextEvent + 685
frame #20: 0x00007fff92803e22 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #21: 0x00007fff927fb1d3 AppKit`-[NSApplication run] + 517
frame #22: 0x00007fff9279fc06 AppKit`NSApplicationMain + 869
frame #23: 0x0000000100001842 River`main(argc=5, argv=0x00007fff5fbff7b0) + 34 at main.m:13
frame #24: 0x00007fff93aed7e1 libdyld.dylib`start + 1

And here's the backtrace when running the tests:

* thread #1: tid = 0x2503, 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x00007fff8ffb6250 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff88ffe708 Foundation`___NSURLConnectionWillCacheResponse_block_invoke_0 + 110
frame #2: 0x00007fff88e86528 Foundation`__65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 28
frame #3: 0x00007fff88e8646c Foundation`-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 227
frame #4: 0x00007fff88e86368 Foundation`-[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 63
frame #5: 0x00007fff88ffda3c Foundation`_NSURLConnectionWillCacheResponse + 126
frame #6: 0x00007fff879f8272 CFNetwork`___delegate_willCacheResponse_block_invoke_0 + 48
frame #7: 0x00007fff87a75a7a CFNetwork`___withDelegateAsync_block_invoke_0 + 90
frame #8: 0x00007fff87b062ea CFNetwork`__block_global_1 + 28
frame #9: 0x00007fff90110154 CoreFoundation`CFArrayApplyFunction + 68
frame #10: 0x00007fff87a667e4 CFNetwork`RunloopBlockContext::perform() + 124
frame #11: 0x00007fff87a666bb CFNetwork`MultiplexerSource::perform() + 221
frame #12: 0x00007fff900f1b31 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #13: 0x00007fff900f1455 CoreFoundation`__CFRunLoopDoSources0 + 245
frame #14: 0x00007fff901147f5 CoreFoundation`__CFRunLoopRun + 789
frame #15: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #16: 0x00007fff88f03f5e Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 268
frame #17: 0x00007fff88f03e0b Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] + 78
frame #18: 0x00000001006beba2 RiverTests`runExampleBlock(block=0x00000001020b68b0, name=0x00000001020b6950) + 562 at SPTExampleGroup.m:31
frame #19: 0x00000001006bfd08 RiverTests`__48-[SPTExampleGroup compileExamplesWithNameStack:]_block_invoke(.block_descriptor=0x00000001020b6a50) + 200 at SPTExampleGroup.m:241
frame #20: 0x00000001006c0877 RiverTests`-[SPTSenTestCase SPT_runExampleAtIndex:](self=0x00000001020e04a0, _cmd=0x0000000100519090, index=0) + 423 at SPTSenTestCase.m:61
frame #21: 0x00000001006c0bfd RiverTests`__33+[SPTSenTestCase testInvocations]_block_invoke(.block_descriptor=0x00000001020e03d0) + 61 at SPTSenTestCase.m:82
frame #22: 0x00000001006c142d RiverTests`-[SPTSenTestInvocation invoke](self=0x00000001020e0170, _cmd=0x00007fff9303afa4) + 93 at SPTSenTestInvocation.m:16
frame #23: 0x00000001007d2a05 SenTestingKit`-[SenTestCase invokeTest] + 164
frame #24: 0x00000001007d2b7f SenTestingKit`-[SenTestCase performTest:] + 173
frame #25: 0x00000001006c11ab RiverTests`-[SPTSenTestCase performTest:](self=0x00000001020e04a0, _cmd=0x00000001007d87f4, run=0x000000010055bb30) + 123 at SPTSenTestCase.m:127
frame #26: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #27: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #28: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #29: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #30: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #31: 0x00000001007d5dc1 SenTestingKit`-[SenTestSuite performTest:] + 125
frame #32: 0x00000001007d2453 SenTestingKit`-[SenTest run] + 65
frame #33: 0x00000001007d4b18 SenTestingKit`+[SenTestProbe runTests:] + 134
frame #34: 0x00007fff88edc395 Foundation`__NSFireDelayedPerform + 358
frame #35: 0x00007fff9012f804 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
frame #36: 0x00007fff9012f31d CoreFoundation`__CFRunLoopDoTimer + 557
frame #37: 0x00007fff90114ad9 CoreFoundation`__CFRunLoopRun + 1529
frame #38: 0x00007fff901140e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #39: 0x00007fff8a660eb4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #40: 0x00007fff8a660b94 HIToolbox`ReceiveNextEventCommon + 166
frame #41: 0x00007fff8a660ae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #42: 0x00007fff92804563 AppKit`_DPSNextEvent + 685
frame #43: 0x00007fff92803e22 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #44: 0x00007fff927fb1d3 AppKit`-[NSApplication run] + 517
frame #45: 0x00007fff9279fc06 AppKit`NSApplicationMain + 869
frame #46: 0x0000000100001842 River`main(argc=8, argv=0x00007fff5fbff6d8) + 34 at main.m:13
frame #47: 0x00007fff93aed7e1 libdyld.dylib`start + 1

The top of these look like the same issue. Is this a problem in my code somewhere (I don't know where it would be) or is there some way to mitigate the issue?

I've tried the typical debugging tips like turning on zombie objects and printing out the contents of the registers when it crashes, neither of those help at all. The registers appear to contain garbage, and having zombies enabled doesn't give any information.

Answer 1

From what I can tell, the actual segfault is caused because target->isa is NULL.

To me this suggests memory overwriting. I would try enabling guard malloc (SO question on how to do that) in hopes of catching something writing past the end of a buffer.

Answer 2

What version of Xcode are you using? I remember seeing something like this when using code coverage with unit tests, but it was fixed in Xcode 4.6. I believe it could be worked around before that by using GCC instead of Clang, but that may or may not be feasible.