2011-09-10 7 views
1

私は、間欠的な間欠的なEXC_BAD_ACCESSクラッシュを文書化しましたhereです。クラッシュが私の欠陥かサードパーティのバグかどうかはどうすればわかりますか?

この質問:これはフレームワーク/ libエラーではないことを確認するためにどのような措置を取ることができ、実際には自分のコードに誤りがありますか? (明らかにそうではありませんが、それは私のコードです。)

私はInstrumentsと苦労してスタックトレースを取得しています。プログラミングのこの側面について学ぶために使用する必要があるリソースはありますか?

EDITは:

#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() 

[OK]を、そしてもう一つ:私は、これはスタックトレースだと思います。

#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() 
+0

デバッグモードでXcodeを使用していて、EXC_BAD_ACCESSでアプリケーションがクラッシュした場合、Xcode内でスタックトレースを取得しないでください。 – whg

+1

これはスタックトレースです。 –

+0

私はxcodeについて何か知りませんが、valgrindというツールがあります。このツールを使用すると、クラッシュの原因を教えてくれることがよくあります。あなたのプログラムが 'foo'と呼ばれ、' valgrind foo'を実行するだけで、プログラムがクラッシュすると、どのメモリが不正にアクセスされたかがわかります。 –

答えて

1

最初のステップは、デバッガーナビゲーターまたはクラッシュログでスタックトレースを調べることです。クラッシュしたスレッドを見つけ、そのスタックを見ます。あなた自身のコードのいずれかがそこにあるならば、あなたのせいかもしれない。

これは法廷に起立しません。一つは、フレームワークやライブラリのコードですべてのことを正しく行い、バグを起こしてしまったかもしれません。バグを乗り越えた瞬間がスタックトレースに捕まった瞬間です(クラッシュが起きた場所なので)。それはまれですが、それは起こります。

もう1つのことは、クラッシュしたスレッドのスタックトレースに独自のコードが表示されない場合、無実であることを証明しないということです。あなたのコードは別のスレッドで有罪になっているかもしれません(通常、スレッドセーフな違反を示しています:安全でないことや間違ったスレッドで知らないうちに、別のスレッドで意図的にスレッドセーフです。あるいは、過去に死亡した可能性があります(死んでいるオブジェクトにメッセージを送ることによって)後​​で発生したクラッシュを(例えば、オブジェクトを過剰にリリースすることによって)発生させました。

バグが誰であるかを判断する唯一の方法は何であれ、調査することです。クラッシュが起きた場所を見つけ、何が起きたのかを見つけ、起きた理由を見つけます。これらの3つのことを知ったら、誰がそれをしたのか、それを修正しなければならないのか(それともあなたのバグ)、それを報告し、回避する必要があるのか​​を知るでしょう。

+0

こんにちは@ピーター、ありがとう!いくつかのこと - 私は基本的に、工場の 'audioRecieved'メソッドを別のライブラリの' FFT'に接続しています。主に見なければならない「いつもの容疑者」はありますか? 第2に、すべてのスレッド*で同じスタックトレースが表示されます。これは正常ではありません、そうですか?オーディオは1つのスレッドで起こっていて、それ以外のものはすべて残しているはずです... – buildsucceeded

+0

@ickydog: "[具体的な事実] [一般的な質問]"そうではありません。私があなたに話したことは、ソリューションへの一般的な道です。特定のプログラムについては何も変わりません。関連性のある唯一の「通常の容疑者」はスレッド不安ですが、それは非常に長いラインナップでは容疑者1人だけです。あなたは、フィールドを取得するためにさらに調査する必要があります。 "すべてのスレッドで*同じスタックトレースが表示されます*。これは正常ではないでしょうか?」あなたが何をしているかによって決まります。あなた(またはあなたのライブラリ)は意図的に同じ関数/メソッドへのスレッドの束から派生していますか?また、Xcodeやクラッシュログで調べていますか? –

+0

Xcodeを見ると、オーディオ用のスレッドと描画用のスレッドがあるはずです。プログラムがまったく動作することを考えれば、これは何らかのXcode表示エラーであると思いますか?それはあなたが実際にすべての肘であることを医者に伝えるようなものです。 – buildsucceeded

関連する問題