How can I tell if a crash is my fault or a 3rd-party bug?

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 -[ofxiPhoneAppDe开发者_如何学运维legate 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 ()

---

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).