いつ、なぜコンパイラは malloc/free/new/delete でメモリを 0xCD、0xDD などに初期化するのですか?

デバッグ モード用にコンパイルされたときに、Microsoft のコンパイラが未所有/初期化されていないメモリのさまざまなビットに使用するものの簡単な要約 (サポートはコンパイラのバージョンによって異なる場合があります):

Value     Name           Description 
------   --------        -------------------------
0xCD     Clean Memory    Allocated memory via malloc or new but never 
                         written by the application. 

0xDD     Dead Memory     Memory that has been released with delete or free. 
                         It is used to detect writing through dangling pointers. 

0xED or  Aligned Fence   'No man's land' for aligned allocations. Using a 
0xBD                     different value here than 0xFD allows the runtime
                         to detect not only writing outside the allocation,
                         but to also identify mixing alignment-specific
                         allocation/deallocation routines with the regular
                         ones.

0xFD     Fence Memory    Also known as "no mans land." This is used to wrap 
                         the allocated memory (surrounding it with a fence) 
                         and is used to detect indexing arrays out of 
                         bounds or other accesses (especially writes) past
                         the end (or start) of an allocated block.

0xFD or  Buffer slack    Used to fill slack space in some memory buffers 
0xFE                     (unused parts of `std::string` or the user buffer 
                         passed to `fread()`). 0xFD is used in VS 2005 (maybe 
                         some prior versions, too), 0xFE is used in VS 2008 
                         and later.

0xCC                     When the code is compiled with the /GZ option,
                         uninitialized variables are automatically assigned 
                         to this value (at byte level). 


// the following magic values are done by the OS, not the C runtime:

0xAB  (Allocated Block?) Memory allocated by LocalAlloc(). 

0xBAADF00D Bad Food      Memory allocated by LocalAlloc() with LMEM_FIXED,but 
                         not yet written to. 

0xFEEEFEEE               OS fill heap memory, which was marked for usage, 
                         but wasn't allocated by HeapAlloc() or LocalAlloc(). 
                         Or that memory just has been freed by HeapFree(). 

免責事項:この表は、私が横たわっているいくつかのメモからのものです。それらは 100% 正しい (または首尾一貫している) とは限りません。

これらの値の多くは、vc/crt/src/dbgheap.c で定義されています:

/*
 * The following values are non-zero, constant, odd, large, and atypical
 *      Non-zero values help find bugs assuming zero filled data.
 *      Constant values are good, so that memory filling is deterministic
 *          (to help make bugs reproducible).  Of course, it is bad if
 *          the constant filling of weird values masks a bug.
 *      Mathematically odd numbers are good for finding bugs assuming a cleared
 *          lower bit.
 *      Large numbers (byte values at least) are less typical and are good
 *          at finding bad addresses.
 *      Atypical values (i.e. not too often) are good since they typically
 *          cause early detection in code.
 *      For the case of no man's land and free blocks, if you store to any
 *          of these locations, the memory integrity checker will detect it.
 *
 *      _bAlignLandFill has been changed from 0xBD to 0xED, to ensure that
 *      4 bytes of that (0xEDEDEDED) would give an inaccessible address under 3gb.
 */

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land with this */
static unsigned char _bAlignLandFill  = 0xED;   /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

デバッグ ランタイムがバッファー (またはバッファーの一部) を既知の値 (たとえば、std::string の「スラック」スペース) で満たす場合もあります。 の割り当てまたは fread() に渡されたバッファ .これらのケースでは、_SECURECRT_FILL_BUFFER_PATTERN という名前の値を使用します (crtdefs.h で定義) )。いつ導入されたのか正確にはわかりませんが、少なくとも VS 2005 (VC++8) まではデバッグ ランタイムに含まれていました。

最初に、これらのバッファを満たすために使用された値は 0xFD でした - 無人の土地に使用されるのと同じ値。ただし、VS 2008 (VC++9) では値が 0xFE に変更されました .これは、たとえば、呼び出し元が fread() に大きすぎるバッファー サイズを渡した場合など、フィル操作がバッファーの末尾を超えて実行される状況が発生する可能性があるためだと思います。 .その場合、値 0xFD バッファ サイズが 1 つでも大きすぎると、フィル値がそのカナリアの初期化に使用された無人地帯の値と同じになるため、このオーバーランの検出がトリガーされない可能性があります。無人地帯に変更がないということは、オーバーランが気付かれないことを意味します。

そのため、VS 2008 で fill 値が変更され、そのような場合にノーマンズ ランド カナリアが変更され、ランタイムによって問題が検出されるようになりました。

他の人が指摘したように、これらの値の重要なプロパティの 1 つは、これらの値のいずれかを持つポインター変数が逆参照されると、アクセス違反が発生することです。標準の 32 ビット Windows 構成では、ユーザー モード アドレス0x7ffffffff を超えることはありません。


塗りつぶし値 0xCCCCCCCC に関する優れたプロパティの 1 つは、x86 アセンブリでは、オペコード 0xCC がソフトウェア ブレークポイント割り込みである int3 オペコードであることです。そのため、その fill 値で満たされた初期化されていないメモリでコードを実行しようとすると、すぐにブレークポイントにヒットし、オペレーティング システムによってデバッガーをアタッチ (またはプロセスを強制終了) させられます。


これはコンパイラと OS 固有のものであり、Visual Studio はさまざまな種類のメモリをさまざまな値に設定するため、デバッガーでは、malloced メモリ、固定配列、または初期化されていないオブジェクトにオーバーランしたかどうかを簡単に確認できます。それらをグーグルで調べて...

http://msdn.microsoft.com/en-us/library/974tc9t1.aspx