应用程序启动时recordingCallback（）中的间歇性崩溃

Question

我的 iOS 应用（使用 openFrameworks）在此行启动时有 30-40% 的时间崩溃：

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

这是ofxiPhoneSoundStream.m中较大的函数内部

static OSStatus recordingCallback(void *inRefCon, 
                              AudioUnitRenderActionFlags *ioActionFlags, 
                              const AudioTimeStamp *inTimeStamp, 
                              UInt32 inBusNumber, 
                              UInt32 inNumberFrames, 
                                  AudioBufferList *ioData) {

我正在使用ofSoundStreamSetup(0, 1, this, 44100, 256, 4); 在setup() 中进行音频设置。

在模拟器中，这种崩溃发生的概率为 100%。知道 (a) 发生了什么或 (b) 如何调试它？

更新：堆栈跟踪：

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

然后Thread 11 AURemoteIO::IOThread: Program received signal: "EXC_BAD_ACCESS"

根据要求，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;
}

上面标记的第 143 行，还有：if(soundInputPtr!=NULL) soundInputPtr->audioIn(tempBuffer, ioData->mBuffers[i].mDataByteSize/2, 1);

添加：

Gameplay::listen() 只是一个最大/最小跟踪器——它过去可以做更多的事情，但我意识到这些功能最好转移到audioRecieved()。其实没有其他代码都在调用这个函数：

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;
}

Answer 1

阅读堆栈跟踪，然后去它告诉你的地方。

#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

在我的该文件副本中，该代码如下所示：

  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

查看文件中的其他位置，basic_string 的析构函数调用该方法以释放字符串的私有存储空间 (_M_rep())。

对于 Objective-C 对象，这样的崩溃通常表明对象本身（在本例中为字符串）被丢弃，通常是通过过度释放它。但我不知道这对 C++ 对象有多大的适用性；在 C++ 和 Objective-C 中，很多事情的工作方式不同。

如果您向我们展示recordingCallback 的代码，我们可能会告诉您更多信息，请确保包含该文件的第 143 行（再次，请参阅堆栈跟踪了解我指向那里的原因）。