objective-c - 启用 "Instrument Program Flow"时 objc_msgSend 中的 EXC_BAD_ACCESS

Question

我花了几天时间试图找出这个问题，但到目前为止还没有成功。

我正在尝试测量我的项目中的测试覆盖率，这是一个使用 Xcode 在 Objective-C 中开发的 Mac OS 应用程序，这意味着在build设置中启用“仪器程序流程”和“生成测试覆盖率文件”。我相信这些对应于 clang 中的 -fprofile-arcs 和 -ftest-coverage 标志。

启用这些功能后(尽管似乎只有 -fprofile-arcs 影响此问题)，程序将崩溃，并在 objc_msgSend 中出现 EXC_BAD_ACCESS 异常> 在某些地方。

当运行应用程序本身时，这会在返回第一个网络请求时发生。回溯不包含我的任何代码，并且似乎完全发生在 Foundation/Cocoa 框架内。虽然这很烦人，但我忍受了根据我是否正在运行测试或使用应用程序来打开/关闭build设置。

我现在在测试时遇到了似乎相同的问题。我刚刚编写了一个包含网络访问的测试，并且在检测程序流时，测试失败，并且在同一位置出现明显相同的异常。

<小时/>

我需要弄清楚是什么原因造成的。我正在开发的应用程序是针对一个大学项目，目标之一是报告测试覆盖率并评估测试过程。当应用程序的大部分由于测试崩溃而无法测试时，这是相当困难的。

* 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

这是运行测试时的回溯:

* 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

这些问题的顶部看起来是同一个问题。这是我的代码中某个地方的问题(我不知道它会在哪里)还是有某种方法可以缓解这个问题？

我尝试过典型的调试技巧，例如打开僵尸对象并在崩溃时打印出寄存器的内容，但这些都没有帮助。寄存器似乎包含垃圾，并且启用僵尸不会提供任何信息。

Answer 1

您使用的 Xcode 版本是什么？我记得在单元测试中使用代码覆盖率时看到过类似的情况，但它在 Xcode 4.6 中得到了修复。我相信在此之前可以通过使用 GCC 而不是 Clang 来解决这个问题，但这可能可行，也可能不可行。