Microsoft derleyicilerinin, hata ayıklama modu için derlendiğinde çeşitli sahipsiz / başlatılmamış bellek bitleri için ne kullandıklarının hızlı bir özeti (destek, derleyici sürümüne göre değişebilir):
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().
Sorumluluk reddi: Tablo, etrafta yatan bazı notlardan geliyor -% 100 doğru (veya tutarlı) olmayabilir.
Bu değerlerin çoğu vc / crt / src / dbgheap.c dosyasında tanımlanmıştır:
/*
* 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 */
Ayrıca, hata ayıklama çalışma zamanının arabellekleri (veya arabellek parçalarını) bilinen bir değerle dolduracağı birkaç kez vardır, örneğin, std::string
's ayırmadaki ' gevşek 'boşluk veya geçirilen arabellek fread()
. Bu durumlarda, ad verilen _SECURECRT_FILL_BUFFER_PATTERN
(içinde tanımlanan crtdefs.h
) bir değer kullanılır . Tam olarak ne zaman tanıtıldığından emin değilim, ancak en azından VS 2005 (VC ++ 8) tarafından hata ayıklama çalışma zamanındaydı.
Başlangıçta, bu tamponları doldurmak 0xFD
için kullanılan değer - hiç kimsenin arazisi için kullanılan değerin aynısıydı. Ancak, VS 2008'de (VC ++ 9) değer olarak değiştirildi 0xFE
. Sanırım bunun nedeni, doldurma işleminin arabelleğin sonundan sonra çalışacağı durumlar olabileceğidir, örneğin, arayan çok büyük bir arabellek boyutunda geçerse fread()
. Bu durumda değer0xFD
bu taşmayı algılamayı tetiklemeyebilir çünkü arabellek boyutu sadece bir kadar büyükse, doldurma değeri o kanaryayı başlatmak için kullanılan no man's land değeriyle aynı olacaktır. Hiç kimsenin toprağında değişiklik olmaması, taşmanın fark edilmeyeceği anlamına gelir.
Böylece VS 2008'de doldurma değeri değiştirildi, böylelikle böyle bir durum kimsenin olmadığı kara kanaryasını değiştirecek ve sorunun çalışma zamanı tarafından tespit edilmesine yol açacaktı.
Diğerlerinin de belirttiği gibi, bu değerlerin temel özelliklerinden biri, bu değerlerden birine sahip bir işaretçi değişkeninin referansı kaldırılırsa, standart bir 32 bit Windows yapılandırmasında kullanıcı modu adresleri olduğundan erişim ihlaline neden olacağıdır. 0x7fffffff'den daha yükseğe çıkmaz.