コンパイラがメモリを特定のパターン、例えば や で初期化することがあるのは知っています0xCD
。0xDD
私が知りたいのはいつそしてなぜこういうことが起こるのです。
いつ
これは使用されているコンパイラに固有のものですか?
これに関しても同じように行動しmalloc/new
、働きますか?free/delete
プラットフォーム固有のものですか?
Linux
やなどの他のオペレーティング システムでも発生しますかVxWorks
?
なぜ
私の理解では、これはデバッグ構成でのみ発生しWin32
、メモリ オーバーランを検出し、コンパイラが例外をキャッチできるようにするために使用されます。
この初期化がどのように役立つか、実際の例を挙げていただけますか?
Win32
メモリを割り当てるときに既知のパターンに初期化するのが良いことであり、特定のパターンは割り込みをトリガーし、デバッガーに例外が表示されるという記述を何かで読んだことを覚えています (おそらく Code Complete 2で)。
これはどれくらい持ち運びやすいですか?
ベストアンサー1
デバッグ モードでコンパイルされるときに、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()
名前で指定された値が使用されます。いつ導入されたかは正確にはわかりませんが、少なくとも VS 2005 (VC++8) までにデバッグ ランタイムに導入されました。_SECURECRT_FILL_BUFFER_PATTERN
crtdefs.h
当初、これらのバッファーを埋めるために使用された値は0xFD
- で、無人地帯に使用された値と同じでした。ただし、VS 2008 (VC++9) では値が に変更されました0xFE
。これは、たとえば呼び出し元が には大きすぎるバッファー サイズを渡した場合など、バッファーの末尾を超えて埋める操作が実行される状況が発生する可能性があるためだと思います。fread()
その場合、0xFD
バッファー サイズが 1 だけ大きすぎると、埋める値はそのカナリアを初期化するために使用された無人地帯の値と同じになるため、値によってこのオーバーランの検出がトリガーされない可能性があります。無人地帯に変更がないということは、オーバーランに気付かないことを意味します。
そのため、VS 2008 では、このような場合に無人地帯カナリアが変更され、ランタイムによって問題が検出されるように、塗りつぶし値が変更されました。
他の人が指摘しているように、これらの値の重要な特性の 1 つは、これらの値のいずれかを持つポインター変数が逆参照されると、アクセス違反が発生することです。これは、標準の 32 ビット Windows 構成では、ユーザー モード アドレスが 0x7fffffff より高くなることはないためです。