_CrtDumpMemoryLeaks切り捨てられた出力？

Question

私は、メモリリークを検出するためのVisual Studioの機能を使用しようとしていますが、私は次のように、切り捨てられた出力を得続ける：私は間違って何をやっている

Dumping objects -> 
{174} normal block at 0x0099ADB8, 48 bytes long. 
Data: <h:\najnovije\tru> 68 3A 5C 6E 61 6A 6E 6F 76 69 6A 65 5C 74 72 75 
{170} normal block at 0x0099AD58, 32 bytes long. 
Data: <h:\najnovije\tru> 68 3A 5C 6E 61 6A 6E 6F 76 69 6A 65 5C 74 72 75 
Object dump complete. 

？私は

#define _CRTDBG_MAP_ALLOC 
#include <stdlib.h> 
#include <crtdbg.h> 

私のコードの冒頭に追加しました。

ありがとうございます。

Answer 1

この出力は切り捨てられません。別の方法で使用することを意図しています。

あなたのプログラムをより深く観察してみてください。同じテストステップを使用する場合は、Visual Studioが常に（より正確には〜99％）、同じリークアドレス0x0099ADB8と0x0099AD58を見つけることができます。

ここで、これらの2つのアドレスの変更を破るデータブレークポイントを設定する必要があります。プログラムの先頭でBreakを選択し、Debug-> New Breakpoint-> New Data Breakpointを選択し、アドレスを入力します。あなたのケースでは、2つを作成する必要があります：1つは0x0099ADB8、もう1つは0x0099AD58です。そして、最終的には、このメモリブロックをインスタンス化するコードに停止し、リークの発生箇所を正確に示します。

毎回異なるリークアドレスがある場合があります。その場合は、代わりにgflagsとWinDBGを使用して、メモリの内容を比較しそこから開始することをお勧めします。

Answer 2

残念ながら、Microsoft Visual C++では、リークの正確な場所を教えてくれません。たとえそうであったとしても、おそらくアプリケーションの一般的なルーチン（AllocateStringのような）や新しい演算子のどこかにあるでしょう。

出力では、\ najnovije \ truはリークの原因となったソースファイルの[切り捨てられた]名前ではありませんが、解放されなかったデータブロックの最初の16バイトです。

アプリケーションにファイル名を保存する場所を探してみてください。おそらく実際のリークを指摘するでしょう。

Answer 3

割り当て元のソースファイル+行番号が必要な場合は、通常のmalloc/newではなくCRTデバッグalloc関数を使用する必要があります。

あなたは「新しい」、あなたはこれを行うことができます使用している場合：

またはmallocのため#define new DEBUG_NEW、代わりにmalloc関数の_malloc_dbgを使用しています。 _malloc_dbgのMSDNドキュメントを読むと、そこにさまざまな項目が表示されます。これを使用するほとんどのマクロはここで__FILE__と__LINE__を使用します。