如何判断崩溃是我的错还是第 3 方错误？
我在此处记录了反复发生的间歇性EXC_BAD_ACCESS崩溃。
这个问题：我可以采取哪些步骤来确保这不是框架/库错误，而实际上是我的代码的错误？ （除了显而易见的，是的，呃，这是我的代码。）
我正在努力使用 Instruments 并获取堆栈跟踪；我应该使用哪些资源来学习这方面的编程？
编辑：我认为这是一个堆栈跟踪：
#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 ()
I have a recurring intermittent EXC_BAD_ACCESS crash documented here.
This question: What steps can I take to make sure that this isn't a framework/lib error, and is actually a fault with my code? (Aside from the obvious, yes, duh, it's my code.)
I'm struggling with Instruments and getting a stack trace; are there resources I should be using to learn about this aspect of programming?
EDIT: I think this is a stack trace:
#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, and another one. Wasn't even sure this was a separate error before:
#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 ()
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第一步是查看调试器导航器或崩溃日志中的堆栈跟踪。找到崩溃的线程并查看其堆栈。如果其中有您自己的代码，很可能是您的错。
这在法庭上是站不住脚的。一方面，您可能已经做对了所有事情并在框架或库代码中触发了错误，而您触发错误的那一刻就是堆栈跟踪中捕获的那一刻（因为那是崩溃发生的地方）。这种情况很少见，但确实会发生。
另一件事是，如果您在崩溃线程的堆栈跟踪中没有看到自己的代码，这并不能证明您是无辜的。您的代码可能在另一个线程上有罪（通常表明违反了线程安全性：您做了一些线程不安全的事情，要么故意在另一个线程上而不知道它不安全，要么不知不觉地在错误的线程上）。或者您过去可能有罪，设置了稍后发生的崩溃（例如，通过过度释放对象）（通过向死亡对象发送消息）。
无论如何，确定是谁的错误的唯一方法就是进行调查。查找崩溃发生的位置、发生的情况以及发生的原因。一旦你知道了这三件事，你就会知道是谁干的，以及你是否必须修复它（你的错误）或报告它并解决它（别人的）。
The first step is to look at the stack trace in the Debugger Navigator or the crash log. Find the crashed thread and look at its stack. If any of your own code is in there, chances are it was your fault.
It won't stand up in court. For one thing, you might have done everything right and tripped a bug in framework or library code, and the moment where you tripped their bug is the moment caught in the stack trace (since that's where the crash happened). It's rare, but it does happen.
The other thing is that if you don't see your own code in the stack trace of the crashed thread, that doesn't prove you innocent. Your code might be guilty on another thread (usually indicating a thread-safety violation: you did something thread-unsafe, either knowingly on another thread without knowing it was unsafe or unknowingly on the wrong thread). Or you might be guilty in the past, having set up a crash to occur (e.g., by over-releasing an object) that occurred later (by messaging the dead object).
No matter what, the only way to determine whose bug it is is to investigate. Find where the crash happened, find what happened, and find why it happened. Once you know those three things, you'll know who did it, and whether you have to fix it (your bug) or report it and work around it (someone else's).