Intermittent crash in recordingCallback() on app launch

My iOS app (using openFrameworks) crashes 30-40% of the time on launch on this line:

    if(soundInputPtr!=NULL) soundInputPtr->audioIn(tempBuffer, ioData->mBuffers[i].mDataByteSize/2, 1);

which is inside the larger function in ofxiPhoneSoundStream.m

  • iOS AUSampler audiounit - file path issue with EXS audio files?
  • unable to receive callback from second view controller
  • iOS Audio Units : When is usage of AUGraph's necessary?
  • How would I create a callback around an XML request?
  • How to use instance method as callback for function which takes only func or literal closure
  • How do I check an MPMediaItem for MPMediaType of just audio?
  • static OSStatus recordingCallback(void *inRefCon, 
                                  AudioUnitRenderActionFlags *ioActionFlags, 
                                  const AudioTimeStamp *inTimeStamp, 
                                  UInt32 inBusNumber, 
                                  UInt32 inNumberFrames, 
                                      AudioBufferList *ioData) {
    

    I am doing audio setup with ofSoundStreamSetup(0, 1, this, 44100, 256, 4); in setup().

    In the simulator this crash happens 100% of the time. Any idea (a) what’s happening or (b) how to debug it?

    Update: Stack trace:

    Thread 11 AURemoteIO::IOThread, Queue : (null)
    
    #0  0x00008ff2 in Gameplay::listen() at /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/usr/include/c++/4.2.1/bits/basic_string.h:238
    #1  0x003178bc in recordingCallback(void*, unsigned long*, AudioTimeStamp const*, unsigned long, unsigned long, AudioBufferList*) at /Developer/of_007_iphone/libs/openFrameworks/sound/ofxiPhoneSoundStream.mm:143
    #2  0x019447e4 in AUIOHelper::NotifyInputAvailable(AudioTimeStamp const&, unsigned long, AudioBufferList const&) ()
    #3  0x0192baf1 in AURemoteIO::PerformIO(unsigned int, unsigned int, XAudioTimeStamp const&, XAudioTimeStamp const&, int&) ()
    #4  0x0192bbc1 in AURIOCallbackReceiver_PerformIO ()
    #5  0x0191b3bf in _XPerformIO ()
    #6  0x01861c11 in mshMIGPerform ()
    #7  0x018e4180 in MSHMIGDispatchMessage ()
    #8  0x019297ba in AURemoteIO::IOThread::Run() ()
    #9  0x0192e8e1 in AURemoteIO::IOThread::Entry(void*) ()
    #10 0x01836972 in CAPThread::Entry(CAPThread*) ()
    #11 0x97bf7259 in _pthread_start ()
    #12 0x97bf70de in thread_start ()
    

    And then Thread 11 AURemoteIO::IOThread: Program received signal: "EXC_BAD_ACCESS"

    As requested, recordingCallback():

    static OSStatus recordingCallback(void *inRefCon, 
                                      AudioUnitRenderActionFlags *ioActionFlags, 
                                      const AudioTimeStamp *inTimeStamp, 
                                      UInt32 inBusNumber, 
                                      UInt32 inNumberFrames, 
                                      AudioBufferList *ioData) {
    
    
        AudioBufferList list;
    
        // redundant
        list.mNumberBuffers = 1;
        list.mBuffers[0].mData = sampleBuffer;
        list.mBuffers[0].mDataByteSize = 2 * inNumberFrames;
        list.mBuffers[0].mNumberChannels = 1;
    
        ioData = &list;
        //printf("No buffers: %d, buffer length: %d bus number: %d\n", ioData->mNumberBuffers, ioData->mBuffers[0].mDataByteSize, inBusNumber);
    
    
        // Then:
        // Obtain recorded samples
    
        OSStatus status = AudioUnitRender(audioUnit, ioActionFlags, inTimeStamp, 1, inNumberFrames, ioData);
        checkStatus(status);
        if(status!=noErr) return status;
        if(ioData->mNumberBuffers>0) {
            int i = 0;
            short int *buffer = (short int *) list.mBuffers[i].mData;
            for(int j = 0; j < ioData->mBuffers[i].mDataByteSize/2; j++) {
                // go through each sample and turn it into a float
                tempBuffer[j] = (float)buffer[j]/32767.f;
    
            }
            done = true;
    
    
          // THIS LINE IS LINE 143
            if(soundInputPtr!=NULL) soundInputPtr->audioIn(tempBuffer, ioData->mBuffers[i].mDataByteSize/2, 1); 
    
        }
        return noErr;
    }
    

    Line 143 marked above, also: if(soundInputPtr!=NULL) soundInputPtr->audioIn(tempBuffer, ioData->mBuffers[i].mDataByteSize/2, 1);

    Added:

    Gameplay::listen() is just a max/min tracker– it used to do more, but I realized those functions were better moved to audioRecieved(). In fact, no other code is calling this function:

    void Gameplay::listen() {
    
      // track extremes for XML purpose
      if (pitchAvg > move.highestPitch) move.highestPitch = pitchAvg;
      if ((pitchAvg < move.lowestPitch) && pitchAvg != 0) move.lowestPitch = pitchAvg;
      if (ampAvg > move.loudestVol) move.loudestVol = ampAvg;
      if ((ampAvg < move.softestVol) && ampAvg > 0.15) move.softestVol = ampAvg;
    }
    

    Solutions Collect From Internet About “Intermittent crash in recordingCallback() on app launch”

    Read the stack trace and go where it tells you.

    #0  0x00008ff2 in Gameplay::listen() at /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/usr/include/c++/4.2.1/bits/basic_string.h:238
    

    In my copy of that file, that code reads as follows:

      void
      _M_dispose(const _Alloc& __a)
      {
    #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
        if (__builtin_expect(this != &_S_empty_rep(), false))
    #endif
          if (__gnu_cxx::__exchange_and_add_dispatch(&this->_M_refcount,
                                 -1) <= 0)
            //Line 238:
            _M_destroy(__a);
      }  // XXX MT
    

    Looking elsewhere in the file, that method is called by basic_string‘s destructor to release the string’s private storage (_M_rep()).

    For Objective-C objects, a crash like that generally indicates that the object itself (in this case, the string) was trashed, usually by over-releasing it. But I don’t know how applicable that is to C++ objects; a lot of things work differently in C++ vs. Objective-C.

    We can probably tell you more if you show us the code for recordingCallback, making sure to include line 143 of that file (again, see the stack trace for why I’m pointing there).