ヒープ割り当て要求の追跡

[アーティクル]
08/09/2011

このトピックの内容は、次の製品に該当します。

エディション	Visual Basic	C#	F#	C++	Web Developer
Express				ネイティブのみ
Pro、Premium、Ultimate				ネイティブのみ

アサートマクロやレポートマクロの場合は、それらが実行されたソースファイル名や行番号を特定することが、問題の原因となっている場所を突き止めるためにたいへん役に立ちますが、これはヒープ割り当て関数には当てはまりません。マクロはアプリケーションの論理ツリー内で適切な位置に挿入されますが、ヒープの割り当ては、さまざまな時点でさまざまな場所から呼び出される特殊なルーチンの中に埋もれていることが多いためです。通常は、不正なヒープ割り当てがコードのどの行で発生しているかではなく、その行で行われる膨大なヒープ割り当てのうち、どの割り当てが、どのような理由で不正になるかということが問題となります。

一意の割り当て要求番号と _crtBreakAlloc

不正となるヒープ割り当て呼び出しを特定するには、デバッグヒープ上の各ブロックに関連付けられている一意の割り当て要求番号を利用する方法が最も簡単です。ダンプ関数を使用してブロックの情報を出力すると、この割り当て要求番号が中かっこで囲まれて表示されます ("{36}" など)。

不正な割り当てブロックの割り当て要求番号が判明したら、この番号を _CrtSetBreakAlloc に渡してブレークポイントを作成できます。このブロックが割り当てられる直前でプログラムの実行が停止するため、その時点からさかのぼって、不正な呼び出しの原因となっているルーチンを突き止めることができます。再コンパイルせずに同じことをデバッガーで行うには、問題の割り当て要求番号を _crtBreakAlloc に設定します。

デバッグ用の独自割り当てルーチンの作成

_dbg の付いたデバッグバージョンのヒープ割り当て関数を使用するのと比べると少し複雑になりますが、デバッグ用に独自の割り当てルーチンを作成する方法もあります。そして、基本のヒープ割り当てルーチンにソースファイルと行番号を引数として渡します。こうすると、不正な割り当てが発生した場所をすばやく見つけることができます。

たとえば、アプリケーションに次のような共用ルーチンがあるとします。

int addNewRecord(struct RecStruct * prevRecord,
                 int recType, int recAccess)
{
    // ...code omitted through actual allocation... 
    if ((newRec = malloc(recSize)) == NULL)
    // ... rest of routine omitted too ... 
}

ヘッダーファイルに、次のようなコードを追加します。

#ifdef _DEBUG
#define  addNewRecord(p, t, a) \
            addNewRecord(p, t, a, __FILE__, __LINE__)
#endif

次に、レコード作成ルーチンによる割り当てを次のように変更します。

int addNewRecord(struct RecStruct *prevRecord,
                int recType, int recAccess
#ifdef _DEBUG
               , const char *srcFile, int srcLine
#endif
    )
{
    /* ... code omitted through actual allocation ... */
    if ((newRec = _malloc_dbg(recSize, _NORMAL_BLOCK,
            srcFile, scrLine)) == NULL)
    /* ... rest of routine omitted too ... */
}

これで、addNewRecord が呼び出された場所のソースファイル名と行番号が、デバッグヒープ上に割り当てられた各ブロックに格納されるため、このブロックを調べれば、これらの情報を出力できます。

参照

その他の技術情報

CRT デバッグヒープ

次の方法で共有

ヒープ割り当て要求の追跡

一意の割り当て要求番号と _crtBreakAlloc

デバッグ用の独自割り当てルーチンの作成

参照

その他の技術情報

その他のリソース