如何判斷崩潰是我的錯還是第三方的錯誤？

我有一個反覆出現的間歇性EXC_BAD_ACCESS崩潰記錄here。如何判斷崩潰是我的錯還是第三方的錯誤？

這個問題：我可以採取哪些步驟來確保這不是框架/ lib錯誤，而且實際上是我的代碼出錯？（除了顯而易見的，是的，嗯，這是我的代碼。）

我正在努力與儀器和獲取堆棧跟蹤;我應該使用哪些資源來了解這方面的編程？

編輯：我覺得這是一個堆棧跟蹤：

#0 0x0000cad8 in std::string ofToString<float>(float const&) at /Developer/of_007_iphone/libs/openFrameworks/utils/ofUtils.h:79 
#1 0x000064ac in testApp::draw()() 
#2 0x0036d78c in ofAppiPhoneWindow::timerLoop()() 
#3 0x0037e698 in -[ofxiPhoneAppDelegate timerLoop]() 
#4 0x3095cbde in __NSFireTimer() 
#5 0x3579eca0 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__() 
#6 0x3579e6ac in __CFRunLoopDoTimer() 
#7 0x3576e300 in __CFRunLoopRun() 
#8 0x3576dd7a in CFRunLoopRunSpecific() 
#9 0x3576dc88 in CFRunLoopRunInMode() 
#10 0x336ace8c in GSEventRunModal() 
#11 0x318f0f94 in -[UIApplication _run]() 
#12 0x318ee4d4 in UIApplicationMain() 
#13 0x0036e9c4 in ofAppiPhoneWindow::runAppViaInfiniteLoop(ofBaseApp*)() 
#14 0x003a6804 in ofRunApp(ofBaseApp*)() 
#15 0x00002b34 in main()

好了，另一個。甚至不知道這是一個單獨的錯誤：

#0 0x00019244 in std::vector<std::complex<float>, std::allocator<std::complex<float> > >::capacity() const at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/bits/stl_vector.h:434 
#1 0x00026608 in std::vector<std::complex<float>, std::allocator<std::complex<float> > >::operator=(std::vector<std::complex<float>, std::allocator<std::complex<float> > > const&) at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/bits/vector.tcc:137 
#2 0x00018708 in Analyzer::calcFFT() at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/gameplay/pitch.cc:86 
#3 0x0001881c in Analyzer::process() at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/gameplay/pitch.cc:197 
#4 0x00004378 in testApp::audioIn(float*, int, int) at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/testApp.mm:362 
#5 0x004a3fa0 in recordingCallback(void*, unsigned long*, AudioTimeStamp const*, unsigned long, unsigned long, AudioBufferList*) at /Developer/of_007_iphone/libs/openFrameworks/sound/ofxiPhoneSoundStream.mm:143 
#6 0x361ccae0 in AUIOHelper::NotifyInputAvailable(AudioTimeStamp const&, unsigned long, AudioBufferList const&)() 
#7 0x361b9b90 in AURemoteIO::PerformIO(unsigned int, unsigned int, XAudioTimeStamp const&, XAudioTimeStamp const&, int&)() 
#8 0x361b9cfc in AURIOCallbackReceiver_PerformIO() 
#9 0x361b0fcc in _XPerformIO() 
#10 0x360dccbc in mshMIGPerform() 
#11 0x36173850 in MSHMIGDispatchMessage() 
#12 0x361c0b5c in AURemoteIO::IOThread::Entry(void*)() 
#13 0x3609ebb4 in CAPThread::Entry(CAPThread*)() 
#14 0x33c14684 in _pthread_start()

來源

2011-09-10 buildsucceeded

當在Debug模式下使用Xcode，並且您的應用程序與EXC_BAD_ACCESS一起崩潰時，Xcode中是否沒有堆棧跟蹤？ – whg

這是一個堆棧跟蹤。 –

我對xcode一無所知，但是有一個名爲valgrind的工具，你可以使用，它會經常告訴你是什麼導致了崩潰。如果你的程序被稱爲'foo'，那麼你只需運行'valgrind foo'，當程序崩潰時，它會告訴你什麼內存被錯誤地訪問。 –

第一步是查看Debugger Navigator或崩潰日誌中的堆棧跟蹤。找到崩潰的線程並查看其堆棧。如果你有自己的代碼，那很有可能是你的錯。

它不會站起來在法庭上。首先，你可能已經做了一切正確的事情，並且在框架或者庫代碼中絆倒了一個bug，並且你跳過bug的那一刻就是陷入棧跟蹤的時刻（因爲這是崩潰發生的地方）。這很少見，但它確實發生。

另一件事是，如果你沒有看到你自己的代碼在崩潰的線程的堆棧跟蹤，這並不證明你是無辜的。你的代碼可能對另一個線程有罪（通常表示線程安全違規：你做了一些線程不安全的事情，或者知道在另一個線程上知道它不安全或不知道在錯誤的線程上）。或者你過去可能會有罪，因爲後來發生了崩潰（例如，通過過度釋放對象）（通過發送死去的對象）。

無論如何，確定問題出在哪裏的唯一方法就是調查。找出撞車發生的地點，找出發生的事情，並找出發生的原因。一旦你知道了這三件事，你就會知道是誰做的，你是否必須修復它（你的bug）或者報告它並且解決它（別人的）。

來源

2011-09-10 19:07:01

嗨@Peter，謝謝！幾件事 - 我基本上只是把一個工廠'audioRecieved'方法連接到另一個庫的'FFT'。主要有哪些「常見的嫌疑犯」？其次，我在*每個線程*中看到相同的堆棧跟蹤。這不可能是正常的，對吧？音頻應該是在一個線程中發生，並將所有其他內容獨自... – buildsucceeded

@ickydog：「[特定事實] [一般問題]」並非如此。我告訴你的是解決問題的一般途徑;沒有任何關於任何特定程序改變它。唯一可能相關的「常見嫌疑犯」是線程不安全，但這只是一個非常長的陣容中的一個嫌疑犯。你需要進一步調查以挖掘該領域。「我在*每個線程中看到相同的堆棧跟蹤*。這不可能是正常的，對吧？「這取決於你在做什麼。你（或你的圖書館）是否故意從一堆線程中產生相同的函數/方法？另外，你在看Xcode，還是在崩潰日誌？ –

尋找Xcode，不，應該有一個線程的音頻和其他線程的東西像繪圖 - 鑑於該程序的作用，你認爲這可能是某種Xcode顯示錯誤？這就像有一個醫生告訴你，你實際上都是肘部。 – buildsucceeded

如何判斷崩潰是我的錯還是第三方的錯誤？

回答

相關問題