當啓用「儀表程序流程」時，在objc_msgSend中執行EXC_BAD_ACCESS

我花了幾天的時間試圖追蹤這個問題，但迄今爲止沒有運氣。當啓用「儀表程序流程」時，在objc_msgSend中執行EXC_BAD_ACCESS

我想在我的項目中使用Xcode在Objective-C中開發的Mac OS應用程序中測量測試覆蓋率，這意味着在構建設置中啓用「Instrument Program Flow」和「Generate Test Coverage Files」。我相信這些對應於鐺中的-fprofile-arcs和-ftest-coverage標誌。

啓用這些功能後（雖然看起來只有-fprofile-arcs影響此問題），但某些地方的程序將在objc_msgSend中發生EXC_BAD_ACCESS異常。

運行應用程序本身時，會在返回第一個網絡請求時發生。回溯不包含我的代碼，並且似乎完全在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

這些頂部看起來像同樣的問題。這是我的代碼中的問題（我不知道它會在哪裏）還是有一些方法來緩解這個問題？

我試過了一些典型的調試技巧，比如打開殭屍對象並在崩潰時打印出寄存器的內容，這些都沒有幫助。寄存器似乎包含垃圾，並且啓用殭屍不會提供任何信息。

來源

2013-03-19 danpalmer

即使你無法調查它，你是否至少得到了殭屍呻吟聲？或者，在殭屍模板下啓用殭屍或在樂器中運行是否完全沒有明顯效果？ – 2013-03-19 18:43:06

另外，我剛剛檢查過，你確定這些構建設置對應於這些標記。 – 2013-03-19 18:49:29

殭屍根本沒有。當我查看objc_msgSend的目標時，它是垃圾數據，而不是解除分配的對象。 – danpalmer 2013-03-19 21:57:11

你使用的是什麼版本的Xcode？我記得在單元測試中使用代碼覆蓋率時看到類似的情況，但它在Xcode 4.6中得到了修復。我相信在使用GCC而不是Clang之前可以解決這個問題，但這可能也可能不可行。

來源

2013-03-21 01:45:03

我正在使用4.6，我不記得我是否在4.5時進行這個測試，所以我不確定這是否在更新之前發生。我嘗試切換到GCC，但是有很多編譯問題，所以目前它不是真的可行。 – danpalmer 2013-03-21 19:09:23

從我所知道的，實際的段錯誤是由於target-> isa爲NULL而引起的。

對我來說這建議記憶覆蓋。我會嘗試啓用後衛malloc（SO question on how to do that），希望能夠捕獲寫入緩衝區末尾的內容。

來源

2013-03-21 01:55:22 cobbal

我一直都有Guard Malloc，根據我的情況看，沒有任何幫助。 – danpalmer 2013-03-21 19:07:50

當啓用「儀表程序流程」時，在objc_msgSend中執行EXC_BAD_ACCESS

回答

相關問題