1

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 ()
Community
  • 1
  • 1
buildsucceeded
  • 4,203
  • 4
  • 34
  • 72
  • When using Xcode in Debug mode, and your app crashes with EXC_BAD_ACCESS, do you not get a stack trace within Xcode? – whg Sep 10 '11 at 14:53
  • i don't know anything about xcode, but there's a tool called valgrind that you can use that will often tell you what caused the crash. if your program is called `foo` then you just run `valgrind foo` and, when the program crashes, it will tell you what memory was being accessed incorrectly. – andrew cooke Sep 10 '11 at 20:08

1 Answers1

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

Peter Hosey
  • 95,783
  • 15
  • 211
  • 370
  • Hi @Peter, thanks! Couple of things-- I'm basically just hooking up a factory `audioRecieved` method to another library's `FFT`. Are there any 'usual suspects' I should look at primarily? Second, I see the same stack trace in *every thread*. This can't be normal, right? Audio is supposed to be happening in one thread and leaving everything else alone... – buildsucceeded Sep 10 '11 at 20:30
  • @ickydog: “[specific fact] [general question]” Not really. What I've told you is the general path to a solution; nothing about any specific program changes it. The only “usual suspect” that might be relevant is thread unsafety, but that's just one suspect in a very long line-up. You need to investigate further to winnow the field. “I see the same stack trace in *every thread*. This can't be normal, right?” It depends on what you're doing. Are you (or your library) deliberately spawning off a bunch of threads to the same function/method? Also, are you looking in Xcode, or at a crash log? – Peter Hosey Sep 10 '11 at 20:56
  • Looking in Xcode, and no, there should be one thread for audio and other threads for things like drawing-- Given that the program works at all, do you think this could be some sort of Xcode display error? It's sort of like having a doctor tell you that you're actually all elbows. – buildsucceeded Sep 10 '11 at 21:16
  • @ickydog: Possibly. Where, exactly, within Xcode did you copy the above stack traces from? – Peter Hosey Sep 10 '11 at 21:20
  • Debug navigator. Out of curiosity I clicked on the disclosure triangle next to other threads after copying, and all showed the same stack. – buildsucceeded Sep 10 '11 at 21:24
  • @ickydog: Strange. That should work. Try running your app on the device, without Xcode attached, and then viewing the crash log in Xcode after you plug back in. Assuming the same crash happens on the device (which can't be guaranteed), the crash log will tell you whether Xcode is right or wrong. – Peter Hosey Sep 10 '11 at 21:29
  • Xcode wrong, threads are different. I am seeing crashes in all sorts of different threads, though, as I look back through the device crash logs... – buildsucceeded Sep 10 '11 at 21:45