2

オーディオ ファイルを開いて読み取ると、毎回この呼び出し元から放棄された malloc ブロックが返されます。

ループでは、このようなデータを設定します (これは、インストルメントのメモリ使用量として 99.7% としてマークされています)。data = (short*)malloc(kSegmentSize*sizeof(short));

free(data);そして、各反復の終わりにこのように解放します。

ここで何が起こっているのかよくわかりません。助けていただければ幸いです。

編集: KSegmentSize は、最小 6000 から最大 50000 (投機的) まで、数千単位で変化します。

楽器のトレース:

ここに画像の説明を入力

ここに画像の説明を入力

4

3 に答える 3

1

単純化することから始めることをお勧めします。たとえば、malloc / freeを除くすべてのコードをコメントアウトします(できれば#if 0を使用します)。コードを実行し、放棄されたヒープブロックがないことを確認します。次に、残りのコードを徐々に再導入し、問題が発生するまで再実行してから、デバッグします。

于 2013-03-23T01:46:53.650 に答える
1

正確なコードがない:

malloc と free の間の何かがスローされているため、この問題が発生していることを確認してください (そして、おそらくすでにそれをキャッチしているので、ループを終了しません)。これが C (または Objective-C) または C++ コードで発生しているかどうかに応じて、解決方法がわずかに異なります。

C++ では、malloc/free を RAII パターンでラップして、スタックが巻き戻されたときに free が呼び出されるようにします。

class MyData {
public:
    A(size_t numShorts) : dataPtr(0) { dataPtr = malloc(numShorts * sizeof(short)); }
    ~A() { free(dataPtr); }
    operator short*() { return dataPtr; }
private:
    short* dataPtr;
}

MyData data(numShorts);
// do your stuff, you can still use data as you were before due the 'operator short*'
// allow the dtor to be called when you go out of scope

Objective-C では、finally ブロックを使用する必要があります。

void* myPtr = 0;
@try { myPtr = malloc(...); }
@catch {}
@finally { free(myPtr); }
于 2013-03-20T11:26:04.487 に答える
0

私自身の質問に答えて申し訳ありませんが、コードをコメントアウトしてスタックトレースをバックアップした後、実際の問題はファイルが破棄されないことでした。

呼び出すExtAudioFileDispose(audioFile);ことで、この隠れたバグが解決されました。Instruments は完全に明確ではなく、malloc をリークとしてマークしました。公平を期すために、ExtAudioOpenFile メソッドによって参照されるファイル内のデータからの malloc で、ファイル参照を破棄しないとリークが発生しました。

于 2013-05-01T14:02:17.433 に答える