到目前为止,我花了几天的时间试图找出这个问题而没有运气。
我正在尝试测量我的项目中的测试覆盖率,这是一个使用Xcode在Objective-C中开发的Mac OS应用程序,这意味着在构建设置中启用“Instrument Program Flow”和“Generate Test Coverage Files”。我相信这些对应于clang中的-fprofile-arcs
和-ftest-coverage
标志。
启用这些功能后(虽然似乎只有-fprofile-arcs
会影响此问题),程序会因某些地方的EXC_BAD_ACCESS
内的objc_msgSend
例外而崩溃。
运行应用程序本身时,会在返回第一个网络请求时发生这种情况。回溯不包含我的代码,似乎完全出现在Foundation / Cocoa框架中。虽然这很烦人,但我还是根据我是在运行测试还是使用应用程序来打开/关闭构建设置。
我现在在测试时遇到了同样的问题。我刚刚编写了一个包含网络访问的测试,并且在测试程序流程时,测试在同一位置显然出现相同的异常。
我需要弄清楚导致这种情况的原因。我正在开发的应用程序用于大学项目,其中一个目标是报告测试覆盖率并评估测试过程。当由于测试崩溃而无法测试大部分应用程序时,这很难做到。
* 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
这些问题的顶部看起来像是同一个问题。这是我的代码中的某个问题(我不知道它会在哪里)或者是否有某种方法来缓解这个问题?
我尝试了一些典型的调试技巧,例如打开僵尸对象并在崩溃时打印出寄存器的内容,这些都没有任何帮助。寄存器似乎包含垃圾,启用僵尸不会提供任何信息。
答案 0 :(得分:0)
您使用的是什么版本的Xcode?我记得在使用代码覆盖与单元测试时看到类似的东西,但它在Xcode 4.6中得到修复。我相信它可以通过使用GCC而不是Clang来解决,但这可能是也可能不可行。
答案 1 :(得分:0)
据我所知,实际的段错是由于target-> isa为NULL引起的。
对我来说,这表明记忆覆盖。我会尝试启用guard malloc(SO question on how to do that),以期在缓冲区末尾写入一些内容。