如何判断崩溃是我的错还是第三方错误?

时间:2011-09-10 14:45:31

标签: xcode language-agnostic stack-trace instruments

我经常发生间歇性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 ()

1 个答案:

答案 0 :(得分:1)

第一步是查看调试器导航器或崩溃日志中的堆栈跟踪。找到崩溃的线程并查看其堆栈。如果你自己的代码在那里,那么这可能是你的错。

它不会在法庭上站起来。首先,你可能已经做了一切正确的事情并且在框架或库代码中绊倒了一个错误,并且你绊倒他们的bug的那一刻就是陷入堆栈跟踪的那一刻(因为那是发生崩溃的地方)。这种情况很少见,但确实发生了。

另一件事是,如果你没有在崩溃的线程的堆栈跟踪中看到自己的代码,那不能证明你是无辜的。你的代码可能在另一个线程上有罪(通常表示线程安全违规:你做了一些线程不安全的事情,要么在另一个线程上明知而不知道它在不正确的线程上不安全或不知情)。或者你过去可能会感到内疚,因为设置了一个崩溃(例如,通过过度释放一个对象)以后发生(通过消息死对象)。

无论如何,确定其错误的唯一方法是进行调查。找到崩溃发生的地方,找到发生的事情,并找出原因。一旦你知道了这三件事,你就会知道是谁做的,你是否必须解决它(你的错误)或报告它并解决它(别人的)。